Faculty of Information Technology
Software Engineering Group

Opened 7 years ago

Closed 7 years ago

#84 closed defect (fixed)

Can not place widget on the NewApplication window (the preview of the app window)

Reported by: Patrik Svestka Owned by:
Priority: major Milestone:
Component: default Keywords:
Cc: Also affects CVS HEAD (eXept version): no


When I try to place a widget e.g. button I'm getting now only warning at the ST/X Launcher:
DisplaySurface? [warning]: lost expose event
DisplaySurface? [warning]: lost expose event

By random I succeed by placing the button but this behavior is extremely annoying as you have to "fight" with the application for the placement.

Attachments (2)

NewApplication_GUI_lost_expose_event.7z (1.0 MB) - added by Patrik Svestka 7 years ago.
DisplayRootView-waitForExpose.st (742 bytes) - added by Jan Vrany 7 years ago.
Maybe fix attempt 1 :-)

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by Jan Vrany

Two observations:

  • Does NOT happen on Linux, looks like a Windows-specific problem (explains why I haven't spotted this :-)
  • Only the drop makes problems. This means, dragging from palette to canvas shows nothing (wrong) and slows down the system (wrong). When you (blidndly) drop by releasing mous button, after a while the widget appears on the canvas. Then it can be moved on canvas without problems. The slowdown is likely that event queue gets full. The cause is not yet known (I need to debug it on Windows)

comment:2 Changed 7 years ago by Patrik Svestka

I made a short screen case to show the issue, so you can see it. Now I found out that it actually shows the widget every time if I don't drag it too far. (the video is packed so it fits here)

Changed 7 years ago by Patrik Svestka

comment:3 Changed 7 years ago by Jan Vrany

Thanks - this looks similar to what I'm experiencing. After a quick look it looks that the the problem is that gets too busy and slow - the CPU just burns. A huge amount of time is spent in LargetInteger arightmetics as OS time is kept in LargetIntegers internally. Under Win64 LargeIntegers is known to be slow and even buggy (known, outstanding bug).

A quick test proved that avoiding a LargeInteger arithmetics in Win32OperatingSystem>>getOSTime (which is poorly code with that respect) significantly improves the situation but still, far from being acceptable. More has to be done (and Win32OS fix has to be thought through - this might be tricky to get 100% correct).

This is more tricky that I thought initially.

Changed 7 years ago by Jan Vrany

Maybe fix attempt 1 :-)

comment:4 Changed 7 years ago by Jan Vrany

Ah...now I recalled a similar bug I fixed for X11. If I apply the same fix for Win32, the issue goes away.

Could you please try this "fix" and confirm if it helps?

comment:5 Changed 7 years ago by Jan Vrany

After a closer look, I found the real cause - I believe - of the problem. My previous fix for the same problem under X11 (ce64e30ecf54/stx.libview) actually cured symptoms, not the disease itself! Reverted in cea144a15948/stx.libview.

A proper (I believe now) fix comes in 83b501bbf3b0/stx.libview and should be in build 2106 and later. Please confirm and - if it works - close the issue :-)

comment:6 Changed 7 years ago by Jan Vrany

Status: newtesting

comment:7 Changed 7 years ago by Patrik Svestka

Yes, this solves the issue tested on build 2107 :).

Now it works perfectly, you can close the issue.

comment:8 Changed 7 years ago by Jan Vrany

Resolution: fixed
Status: testingclosed
Note: See TracTickets for help on using tickets.