Gecko:NativeWidgetOverhaul: Difference between revisions

m
rv for and on behalf of Biesi
No edit summary
m (rv for and on behalf of Biesi)
 
(4 intermediate revisions by 2 users not shown)
Line 17: Line 17:
* Every time content geometry changes in a way that affects the positioning or clipping of a plugin, we reflect that change by repositioning the clipping and plugin widgets and changing the size of the clipping widget.
* Every time content geometry changes in a way that affects the positioning or clipping of a plugin, we reflect that change by repositioning the clipping and plugin widgets and changing the size of the clipping widget.
* To scroll, we do in-window bitblits of the main window and reconfigure the plugin/clipping widgets.
* To scroll, we do in-window bitblits of the main window and reconfigure the plugin/clipping widgets.
This will require hooking up all viewmanagers in a window into a single tree. Currently view managers in content subshells of chrome shells are not hooked up to their parent.


To scroll a page where the plugins must move, here's how it could work:
To scroll a page where the plugins must move, here's how it could work:
* Scroll requests are queued up until we're ready for a repaint
* Scroll requests are queued up until we're ready for a repaint
* We figure out which parts of the window will need to be repainted after
* We figure out which parts of the window will need to be repainted after scrolling has happened and plugins have moved
scrolling has happened and plugins have moved
* That area is rendered to an offscreen buffer
* That area is rendered to an offscreen buffer
* We perform the scroll operations
* We perform the scroll operations
Line 31: Line 32:
* Greatly reduced usage of native widgets
* Greatly reduced usage of native widgets
* Much code removal
* Much code removal
* Plugins get clipped properly in all situations where the clip area is rectilinear (currently they don't in some cases)
* Plugins get clipped properly in all situations where the clip area is rectilinear (currently they don't in some cases), or even to arbitrary regions
* Possibly increased flicker/redrawing when plugins are present, in some cases, but only for windowed, non-encapsulated plugins. And if we're clever we can minimize it. (Basically, delay reconfiguration of plugin/clipping widgets until we paint the toplevel window. Then render into the backbuffer, *then* reconfigure plugin/clipping widgets, then blast the backbuffer out.)
* Possibly increased flicker/redrawing when plugins are present, in some cases, but only for windowed, non-encapsulated plugins.


Popup windows (menus and combobox dropdowns) would be handled as toplevel windows.
Popup windows (menus and combobox dropdowns) would be handled as toplevel windows.
Line 40: Line 41:
* Will this be acceptable for plugins?
* Will this be acceptable for plugins?
* How will various platforms cope, especially Cocoa, where scrollbars are native widgets?
* How will various platforms cope, especially Cocoa, where scrollbars are native widgets?
* This will cause some problems for accessibility, which currently depends on native widgets being attached to the browser content window, but Aaron thinks he can deal with it.


It looks like Cocoa might be able to paint scrollbars via NSSliderCell.
It looks like Cocoa might be able to paint scrollbars via NSSliderCell.
Confirmed users
269

edits