Bug 91727 - Linux OS File Picker Blocks Canvas Repaints
Summary: Linux OS File Picker Blocks Canvas Repaints
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.0.0.0.beta1
Hardware: Other Linux (All)
: medium normal
Assignee: Michael Meeks
URL:
Whiteboard: target:5.1.0 target:5.0.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: VCL-Scheduler
  Show dependency treegraph
 
Reported: 2015-05-29 18:17 UTC by Dave Richards
Modified: 2017-10-13 16:12 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Move the file picker around and the canvas does not repaint. (410.27 KB, image/png)
2015-05-29 18:17 UTC, Dave Richards
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2015-05-29 18:17:49 UTC
Created attachment 116145 [details]
Move the file picker around and the canvas does not repaint.

Using 5.0 on Linux and using the native OS picker, if you do a file > open, it's not firing in a new thread and the canvas in the background is blocked from repaints as the dialog is moved around.

If you configure LO to use the native file picker, this symptom is not seen and the dialog can be moved and the canvas repaints.  So in some way these two dialogs are being fired differently.

This leads users to think LO has deadlocked.

Attaching screenshot.
Comment 1 Buovjaga 2015-05-29 19:15:53 UTC
Not reproduced. DE: Unity, in a VM.

Ubuntu 15.04 64-bit 
Version: 5.1.0.0.alpha1+
Build ID: be01d68420086fc36ecf26b5f597ba7c6b29b369
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-05-28_03:30:12
Locale: en-US (en_US.UTF-8)
Comment 2 Dave Richards 2015-05-29 20:29:13 UTC
Added Michael Meeks per his IRC request.

I have a bit more information. This is happening on 5.0 snapshot from 5-27.  I installed the snapshot from 5-29 on another server and performed the same test and it's doing the same thing.  So it's multiple users, happens with .config folder completely wiped.

This is being tested over NX technology, similar to remote X but with compression.  Most similar technology to this would be VNC.  Maybe it's not seen when the video card is local.

I still feel that whatever is happening is easily fixed because the LO native dialog works perfectly and does not leave artifacts.

I can maybe bibisect if not replicated or seen elsewhere.
Comment 3 Terrence Enger 2015-06-01 22:52:26 UTC
I see a failure to repaint in (chroot to) debian-sid with daily
dbgutil version 2015-06-01 ...
    Version: 5.1.0.0.alpha1+
    Build ID: e61fcfea5c2a306e44a053976e921160e78917ac
    Locale: en-CA (en_CA.UTF-8)
and with LibreOffice version ...
    Version: 5.0.0.0.beta1
    Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3
    Locale: en-CA (en_CA.UTF-8
but not with ...
    Version: 4.5.0.0.alpha0+
    Build ID: a272f5b7b30f356418ecf28eb95d066f081d1624
    TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-09_09:50:59
    Locale: en_CA
nor with ...
    Version: 5.1.0.0.alpha1+
    Build ID: 1a8e9dae32997bf199dbd192058fcd8f187ddc49
    TinderBox: Win-x86@39, Branch:master, Time: 2015-05-31_03:55:23
    Locale: en-CA (en_CA)
so I am setting keyword regression.

However, contrary to Dave's experience, I see the problem only with
native dialogs, not with LibreOffice dialogs.

I have not succeeded in finding a duplicate bug report, so setting
status NEW.
Comment 4 Michael Meeks 2015-06-02 12:19:30 UTC
Heh ; so the gtk+ file picker was never in a separate thread. It does seem however to pretty vigorously grab focus - and indeed appears to inhibit other windows from rendering when it's visible - most unusual =)
Of course with a modern compositing WM you tend not to see that happening so easily; but grabbing focus from all other app windows is annoying indeed - but that in itself is no regression; the open dialog was confusingly application-modal in 4.3. None of the commits in vcl/unx/gtk/fpicker look at all suspicious since 4.3 either - so I guess perhaps more of a core gtk+ or RenderContext issue.
Comment 5 Dave Richards 2015-06-03 14:47:29 UTC
Performed bibisect and it can clearly be seen in the 5.0 version.  Continued through until bibisect reported:


The first bad commit could be any of:
891b689ba95b9e53609194ee2a1a2d3b8955843c
18afb8632caa524fbc70ed5ce3808e23e5dad16f
We cannot bisect more!
Comment 6 Matthew Francis 2015-06-03 14:59:13 UTC
The range in comment 5 maps to 9e678c14e4fc8e58b1e0530744f648fa3958d338..d05a64df34fd143670cb939b72abfb32d6b714c7 on master, which is the Timer/Idle work

Adding Cc: to tobias.madl.dev@gmail.com; Could you possibly take a look at this one? Thanks
Comment 7 Michael Meeks 2015-06-08 09:23:03 UTC
If bisected to idle / timer - it's not rendercontext =)
Comment 8 Michael Meeks 2015-06-08 16:20:48 UTC
We get the signalExpose we expect with the right (or a plausible) GdkEvent area to re-render, that hits winproc.cxx's ImplHandlePaint - this queues an invalidate - pWindow->ImplInvalidateOverlapFrameRegion which (I assume) never comes back while the dialog is there.
Comment 9 Michael Meeks 2015-06-08 16:50:46 UTC
So - paint.cxx ImplPostPaint doesn't start the maPaintIdle - since it is already active (cf. the IsActive() call in there).

Heh - the bug is pretty comic. The Idle is added, but unfortunately it never triggers the backend to post the idle event or adjust the timeout. I'll need to  add an 'Idle::Start' method to wakeup the backend and get things going.

I imagine that most idles only happened to work because there was an existing timeout being processed there that they could piggy-back on - wow.
Comment 10 Michael Meeks 2015-06-09 20:44:14 UTC
It looks like the idle backend uses the default Scheduler implementation of:

sal_uInt64 Idle::UpdateMinPeriod( sal_uInt64 nMinPeriod, sal_uInt64 nTime )

which looks really unhelpful =) the min. period for any idle should be 0 or 1 depending how you look at things.
Comment 11 Michael Meeks 2015-06-10 10:52:30 UTC
This seems like a feature Lubos added:

commit 06d731428ef6cf93c7333e8228bfb6088853b52f
Author: Luboš Luňák <l.lunak@collabora.com>
Date:   Sat Jan 31 17:40:48 2015 +0100

    make idle timers actually activate only when idle
    
    Without this, they can activate after any call to the event processing,
    so they may activate in cases such as when updating progressbar while
    loading a document, or on repeated user input (so things like showing
    spellchecking get updated when the app is busy redrawing). This change
    makes idle timers activate only when there's nothing more for the event
    loop to process. It's a bit of a question if this doesn't break something
    that happens to expect idle timers to be not-really-idle timers, but oh well.

I guess - its not an entirely obvious feature, its Linux-only, and now re-rendering is done in an idle handler =)

So - I think I'll re-do this to special-case rendering to be allowed in this case.
Comment 12 Michael Meeks 2015-06-10 11:23:16 UTC
Fix in: https://gerrit.libreoffice.org/16205 pending a CI build.
Comment 13 Commit Notification 2015-06-10 16:21:04 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=48c2815dd20cf20eeec8bb4e003000f4a3d13291

tdf#91727 - Unwind non-dispatch of idle handlers.

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Michael Meeks 2015-06-10 17:09:29 UTC
Queued in gerrit for -5-0 as well. Thanks for the report.
Comment 15 Commit Notification 2015-06-15 16:21:24 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ee1e267f8811285c5d526f9b698897b2043059c&h=libreoffice-5-0

tdf#91727 - Unwind non-dispatch of idle handlers.

It will be available in 5.0.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 Robinson Tryon (qubit) 2015-12-17 09:13:16 UTC Comment hidden (obsolete)