After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744604 - stage: Process state update event immediately
stage: Process state update event immediately
Status: RESOLVED FIXED
Product: clutter
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: clutter-maint
clutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-16 16:47 UTC by Lionel Landwerlin
Modified: 2015-02-16 17:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
stage: Process state update event immediately (1.13 KB, patch)
2015-02-16 16:47 UTC, Lionel Landwerlin
none Details | Review
stage: Process state update event immediately (1.21 KB, patch)
2015-02-16 16:50 UTC, Lionel Landwerlin
needs-work Details | Review
stage: Process state update event immediately (1.99 KB, patch)
2015-02-16 17:15 UTC, Lionel Landwerlin
committed Details | Review

Description Lionel Landwerlin 2015-02-16 16:47:29 UTC
The _clutter_stage_update_state() function is currently putting events
into the Clutter event queue. This leads to problems in the gdk
backend because there are assumptions upon the numbers of queued
events, and how many of them should be moved from the main event queue
to the ClutterStages' event queues.

This change triggers the processing of the state update events on the
stage directly, so the main event queue retains the expected number of
events.
Comment 1 Lionel Landwerlin 2015-02-16 16:47:32 UTC
Created attachment 296952 [details] [review]
stage: Process state update event immediately
Comment 2 Lionel Landwerlin 2015-02-16 16:50:43 UTC
Created attachment 296954 [details] [review]
stage: Process state update event immediately

The _clutter_stage_update_state() function is currently putting events
into the Clutter event queue. This leads to problems in the gdk
backend because there are assumptions upon the numbers of queued
events, and how many of them should be moved from the main event queue
to the ClutterStages' event queues.

This change triggers the processing of the state update events on the
stage directly, so the main event queue retains the expected number of
events.
Comment 3 Emmanuele Bassi (:ebassi) 2015-02-16 17:02:46 UTC
Review of attachment 296954 [details] [review]:

it looks good; one minor comment.

::: clutter/clutter-stage.c
@@ +4551,3 @@
 
+  clutter_stage_event (stage, event);
+  clutter_event_free (event);

how about you just put the event on the stack, so we don't have to deal with an additional allocation?
Comment 4 Lionel Landwerlin 2015-02-16 17:07:48 UTC
There is some logic in clutter-event.c : https://git.gnome.org/browse/clutter/tree/clutter/clutter-event.c#n1198

If you're comfortable with by passing that, I'll do it.
Comment 5 Emmanuele Bassi (:ebassi) 2015-02-16 17:11:55 UTC
(In reply to Lionel Landwerlin from comment #4)
> There is some logic in clutter-event.c :
> https://git.gnome.org/browse/clutter/tree/clutter/clutter-event.c#n1198
> 
> If you're comfortable with by passing that, I'll do it.

in this specific case, it does not matter at all. stage state events do not have ancillary data; the only reason we allocated them was because they were going on the stage specific queue, so they had to survive until the queue got consumed.
Comment 6 Lionel Landwerlin 2015-02-16 17:15:46 UTC
Created attachment 296956 [details] [review]
stage: Process state update event immediately

The _clutter_stage_update_state() function is currently putting events
into the Clutter event queue. This leads to problems in the gdk
backend because there are assumptions upon the numbers of queued
events, and how many of them should be moved from the main event queue
to the ClutterStages' event queues.

This change triggers the processing of the state update events on the
stage directly, so the main event queue retains the expected number of
events.
Comment 7 Emmanuele Bassi (:ebassi) 2015-02-16 17:19:17 UTC
Review of attachment 296956 [details] [review]:

looks good.
Comment 8 Lionel Landwerlin 2015-02-16 17:21:24 UTC
Review of attachment 296956 [details] [review]:

Pushed to master.