Bug 38814 - Snappier rendering: paint at idle, not on timeout
Summary: Snappier rendering: paint at idle, not on timeout
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: EasyHack DifficultyInteresting SkillC...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-30 07:09 UTC by Björn Michaelsen
Modified: 2014-10-18 20:28 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Björn Michaelsen 2011-06-30 07:09:28 UTC
Snappier rendering: paint at idle, not on timeout

Background: Currently LibreOffice repaints its screen after a given timeout - this is less than ideal - we should instead use an 'idle' concept such as other toolkits use for painting instead of timeouts. This would involve adding a set of prioritised handlers to be run when nothing is coming in from sockets. See vcl/source/window/window.cxx /maPaintTimer/ for the current state of affairs (30ms delay-to-render, 50ms to resize). See also vcl/unx/gtk/app/gtkdata.cxx's impl. of the polling interface: StartTimer / StopTimer etc. we need to add idle handlers with variable priorities / ordering too.

Skills: building, C++, mainloop understanding
Comment 1 Florian Reisinger 2012-05-18 08:56:50 UTC
Deteted "Easyhack" from summary
Comment 2 Björn Michaelsen 2013-10-04 18:48:03 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 3 Michael Meeks 2014-10-18 20:28:12 UTC
There is work going on on this topic at Munich; with some details in the wiki here: https://wiki.documentfoundation.org/Development/LHM_LiMux/Main_Loop


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.