rendercontext double bufgering
play

Rendercontext & Double-Bufgering By Jan Holesovsky @JHolesovsky - PowerPoint PPT Presentation

Rendercontext & Double-Bufgering By Jan Holesovsky @JHolesovsky <kendy@collabora.com> @CollaboraOffjce www.CollaboraOffjce.com VCL changes... VCL (Visual Class Library) LibreOffjce's graphics toolkit ~20 year history


  1. Rendercontext & Double-Bufgering By Jan Holesovsky @JHolesovsky <kendy@collabora.com> @CollaboraOffjce www.CollaboraOffjce.com

  2. VCL changes... ● VCL (Visual Class Library) ● LibreOffjce's graphics toolkit ● ~20 year history ● Undergoing a major upgrade to allow modern features like OpenGL support ● Attend the Michael's VCL talk ● The rendercontext is just part of the entire picture LibreOffice Conference 2015, Aarhus | Jan Holesovsky 2 / 14

  3. When do we draw? ● Before the RenderContext rework started, Paint() methods were called just at any time ● When painting (that's OK of course) ● But also in event handlers (key press, mouse over efgect, …) ● T riggered by timer ● Any other random time (eg. in Writer – the debug rectangle at the top left when layout fjnishes) LibreOffice Conference 2015, Aarhus | Jan Holesovsky 3 / 14

  4. Ideal state ● Painting triggered in a controlled way ● Only the Paint() methods paint ● Only VCL triggers the paint – Consequently it can control the conditions of the paint – various setups / tear downs etc. ● Everything else only invalidates the area – And VCL decides when to paint, and what ● Painting de-coupled from vcl::Window ● vcl::Window becomes more abstract LibreOffice Conference 2015, Aarhus | Jan Holesovsky 4 / 14

  5. RenderContext – what's that? ● RenderContext: class that implements the drawing ● At the moment, vcl::Window inherits from OutputDevice which allows all the painting at random points of time – That's what we want to avoid ● Instead, RenderContext is an implementation of the OutputDevice ● And is passed as a param of the Paint() method ● vcl::Window paints only in Paint() LibreOffice Conference 2015, Aarhus | Jan Holesovsky 5 / 14

  6. Problems with direct paints ● Direct paints are problematic, because the render context is not available ● The code that previously called Paint() directly now has to use Invalidate() ● Invalidate()s are fast now – thanks to the Idle work ● Rework to use Invalidate() has to be done carefully though ● Danger of Invalidate() loops LibreOffice Conference 2015, Aarhus | Jan Holesovsky 6 / 14

  7. Double-bufgering ● Easy once RenderContext is used everywhere ● vcl/source/window/paint.cxx responsible for the rendering in the right order ● For double-bufgering, additionally: – Bufger set up before calling paint (VirtualDevice) – Then call the Paint()s (as before) – Copy the bufger to the screen when done LibreOffice Conference 2015, Aarhus | Jan Holesovsky 7 / 14

  8. Rendercontext rework ● Easy parts ● Adding the RenderContext parameter (via clang plugin) ● Hard parts ● Everything else :-) ● Implemented by T omaž Vajngerl and Miklos Vajna ● Laszlo Nemeth and others nailed down many bugs – thank you! LibreOffice Conference 2015, Aarhus | Jan Holesovsky 8 / 14

  9. Hard parts of the work ● Direct paints stateful in many cases ● Background set once in a constructor, instead of the Paint method ● OutputDevice cached ● Many places just try to remember the OutputDevice, and paint to it later ● Blinking cursor ● Currently it just inverts what is on the screen ● Size of the window vs. size of the rendercontext confusion LibreOffice Conference 2015, Aarhus | Jan Holesovsky 9 / 14

  10. Current status ● Currently ● Most of the classes modifjed to paint only in the Paint() methods ● StartCenter completely double-bufgered ● Writer mostly double-bufgered – Except text cursor – needs inverting still – and some deep pieces ● Try yourself: export VCL_DOUBLEBUFFERING_FORCE_ENABLE=1 ● LibreOffice Conference 2015, Aarhus | Jan Holesovsky 10 / 14

  11. DEMO

  12. TODO ● T ext cursor ● Inverting not convenient; should we have it as a fmat rectangle? [as in Firefox etc.] ● Switch it on for StartCenter and Writer ● Cleanup ● Get rid of the code paths that are not needed for double-bufgering ● Implement it for Calc, Impress and Base LibreOffice Conference 2015, Aarhus | Jan Holesovsky 12 / 14

  13. And further... ● Switch all the drawing to tiled rendering ● Paint methods would not paint the entire screen, but only 256x256 'tiles' ● Currently used on Android & LibreOffjce On-Line ● Adding Desktop would make it one code path again ● Would allow extremely fast OpenGL scrolling / panning / zoom LibreOffice Conference 2015, Aarhus | Jan Holesovsky 13 / 14

  14. Questions? Thanks for listening! LibreOffice Conference 2015, Aarhus | Jan Holesovsky 14 / 14

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend