Hey Devs,
Blocking bug lp:850992 [1] is proving impossible to get a handle on for different devs who are not familiar with the blend code base and it's resisting attempts to let us learn about it.
We could do with a heavy-hitting genius who hopefully knows something about the blend modes for layers to figure this out. I'm betting it's a single line fix when the little worm is rooted out.
To reproduce: Make a new layer with a blend mode other than normal. Group any objects together.
Grouping fails to refresh, ungrouping works as expected. The area isn't being cleared by the redraw method like the text bug (I checked), the redraw is simply failing to happen at all. Tracing the update events is what's causing some headaches since both upstream and downstream tracing just seems to vanish.
Thanks for your help.
Best Regards, Martin Owens
2013/9/28 Martin Owens <doctormo@...400...>:
Hey Devs,
Blocking bug lp:850992 [1] is proving impossible to get a handle on for different devs who are not familiar with the blend code base and it's resisting attempts to let us learn about it.
We could do with a heavy-hitting genius who hopefully knows something about the blend modes for layers to figure this out. I'm betting it's a single line fix when the little worm is rooted out.
I found the following clues:
1. After grouping, I can only select the invisible top rectangle by clicking on the part where it should obscure the lower one. Clicking on the parts where it should be drawn, but there is nothing below it has no effect. This indicates that there is something seriously wrong going on with bboxes. 2. The invisibility persists when zooming in/out, indicating that the display tree is in this incorrect state even after a call to Drawing::update() that should force-update everything (reset = STATE_ALL) and a full redraw.
PS: This is probably unrelated to this bug, but the recently introduced code handling _filter_bbox is wrong. _filter_bbox should NOT be set using area_enlarge(). area_enlarge() is intended to compute the dependency region of the filter, and exists only because we render in tiles. _drawbox must ultimately come from SVG data, because the filter effect region is specified explicitly in the SVG (by default it corresponds to 120% of the object width and height), rather than implicitly by the filter primitives used.
Regards, Krzysztof
I wrote some lib2geom pretty printers to help debug this problem. They are in lib2geom's new 'tools' directory. To use them, add the following to .gdbinit:
python import sys sys.path.insert(0, '/path/to/checkout/of/lib2geom/tools') from lib2geom_gdb import register_lib2geom_printers register_lib2geom_printers() end
Using them, I found that this bug is actually a manifestation of two problems: 1. After grouping, _filter_bbox on the DrawingGroup representing the layer is empty. It seems that SPGroup does not update the filter bbox when a child is removed / added. 2. _drawbox on the same group is totally wrong (it has 1x1 size).
Problem 2 might actually be related to the wrongness of the _filter_bbox code I mentioned earlier.
Regards, Krzysztof
On Sun, 2013-09-29 at 21:35 +0200, Krzysztof Kosiński wrote:
Problem 2 might actually be related to the wrongness of the _filter_bbox code I mentioned earlier.
That wouldn't only be true for groups with a filter on them. I don't think the blend mode setting changes the group's filter checks and if it were, the ungroup would behave the same way since all bugs relating to that were symmetrical.
Martin,
It looks like the bug is actually in SPRect. It happens because of the following interaction:
SPGroup::update() chains up to SPItem::update(), which in turns calls the SPItem::bbox() virtual method to set the filter bounds. However, SPShape uses this->_curve to compute the bounding box, and SPRect only sets the curve when SPRect::update() is called. Consequently, calling SPItem::bbox on an SPRect before it is updated returns an empty bbox.
To fix this, SPRect should either provide its own implementation of the bbox method that does not use _curve, or (preferably) update the curve in the set() method.
Regards, Krzysztof
On 30-9-2013 0:12, Krzysztof Kosiński wrote:
It looks like the bug is actually in SPRect. It happens because of the following interaction:
SPGroup::update() chains up to SPItem::update(), which in turns calls the SPItem::bbox() virtual method to set the filter bounds. However, SPShape uses this->_curve to compute the bounding box, and SPRect only sets the curve when SPRect::update() is called. Consequently, calling SPItem::bbox on an SPRect before it is updated returns an empty bbox.
To fix this, SPRect should either provide its own implementation of the bbox method that does not use _curve, or (preferably) update the curve in the set() method.
I assume this applies to the other "generated" shapes too? (ellipse, star,...)
Cheers, Johan
2013/9/30 Johan Engelen <jbc.engelen@...2592...>:
I assume this applies to the other "generated" shapes too? (ellipse, star,...)
Yes.
However, I found a much simpler solution that does not involve touching the shape code. We simply need to update the children of the group before updating the group itself. The fix is in r12643.
If there is any other object that updates its children after updating itself, it is also broken and needs to be fixed.
Regards, Krzysztof
On Tue, 2013-10-01 at 02:10 +0200, Krzysztof Kosiński wrote:
However, I found a much simpler solution that does not involve touching the shape code. We simply need to update the children of the group before updating the group itself. The fix is in r12643.
Krzysztof, you've saved my bacon on that bug. It was quite hard to understand but you've fixed it :-)
We now only have 3 blockers, one of which is in progress. I'm really hoping that they're actually fixed, but #1005892 might relate to what you were saying before.
What's important to note about the filter_bbox changes is that is all got reverted. The only real difference is the name of the variable. The garbage bbox probably was happening before, I certainly saw weird stuff.
Only the text calculation needs repair if it's getting the wrong bbox. Other shapes don't go through that new enlargement code, just filtered text.
If there is any other object that updates its children after updating itself, it is also broken and needs to be fixed.
If simple tests are working, then we can only wait for bug reports.
HUZZAR!
Martin,
On 2013-10-01 02:10 +0200, Krzysztof Kosiński wrote:
2013/9/30 Johan Engelen <jbc.engelen@...2592...>:
I assume this applies to the other "generated" shapes too? (ellipse, star,...)
Yes.
However, I found a much simpler solution that does not involve touching the shape code. We simply need to update the children of the group before updating the group itself. The fix is in r12643.
If there is any other object that updates its children after updating itself, it is also broken and needs to be fixed.
Probably related: - Bug #304407 “After ungrouping or decoupling a clone blur is no longer shown but style attribute still present.” https://bugs.launchpad.net/inkscape/+bug/304407 (Note: in trunk, the clone disappears from canvas)
Still reproducible with r12645: 1) draw a shape 2) clone it 3) blur the clone 4) group the blurred clone
-> clone disappears.
On 2013-10-01 02:10 +0200, Krzysztof Kosiński wrote:
2013/9/30 Johan Engelen <jbc.engelen@...2592...>:
I assume this applies to the other "generated" shapes too? (ellipse, star,...)
Yes.
However, I found a much simpler solution that does not involve touching the shape code. We simply need to update the children of the group before updating the group itself. The fix is in r12643.
If there is any other object that updates its children after updating itself, it is also broken and needs to be fixed.
Assuming that later revisions 12645, 12647 and 12648 are all somewhat related to the same rendering/update problems:
With latest builds, why are lots of these warnings:
WARNING **: bbox unset when picking
generated when hovering an object if an empty layer (group) is present and visible (empty layer group has to be lower in z-order than the hovered object)?
Steps to reproduce: 1) launch current trunk (default prefs, default new doc) 2) add a new layer 3) draw a shape on the new layer 4) move the cursor over the canvas, watch console --> warning is generated whenever cursor is over a selectable object 5) hide 'Layer 1' (empty) --> warnings stop
Related code: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/annotate/head:/src/display/drawing-item.cpp#L748
2013/10/2 su_v <suv-sf@...58...>:
Assuming that later revisions 12645, 12647 and 12648 are all somewhat related to the same rendering/update problems:
With latest builds, why are lots of these warnings:
WARNING **: bbox unset when picking
generated when hovering an object if an empty layer (group) is present and visible (empty layer group has to be lower in z-order than the hovered object)?
Steps to reproduce:
- launch current trunk (default prefs, default new doc)
- add a new layer
- draw a shape on the new layer
- move the cursor over the canvas, watch console
--> warning is generated whenever cursor is over a selectable object 5) hide 'Layer 1' (empty) --> warnings stop
I assumed that the _bbox always has to be set and forgot about the empty layer/group scenario.
I'll remove the warning shortly.
Regards, Krzysztof
On 2013-10-02 20:17 +0200, Krzysztof Kosiński wrote:
2013/10/2 su_v <suv-sf@...58...>:
Assuming that later revisions 12645, 12647 and 12648 are all somewhat related to the same rendering/update problems:
With latest builds, why are lots of these warnings:
WARNING **: bbox unset when picking
generated when hovering an object if an empty layer (group) is present and visible (empty layer group has to be lower in z-order than the hovered object)?
Steps to reproduce:
- launch current trunk (default prefs, default new doc)
- add a new layer
- draw a shape on the new layer
- move the cursor over the canvas, watch console
--> warning is generated whenever cursor is over a selectable object 5) hide 'Layer 1' (empty) --> warnings stop
I assumed that the _bbox always has to be set and forgot about the empty layer/group scenario.
I'll remove the warning shortly.
Thanks, much appreciated (r12654).
Lately, console is often filled with these types of warnings too:
WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4
I haven't attempted to figure out what triggers them exactly (node-editing path parameters of LPEs seems to be among the actions which tend to produce lots of them).
Is this something you'd like to have more feedback about?
Regards, V
2013/10/5 su_v <suv-sf@...58...>:
Lately, console is often filled with these types of warnings too:
WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4
I haven't attempted to figure out what triggers them exactly (node-editing path parameters of LPEs seems to be among the actions which tend to produce lots of them).
Is this something you'd like to have more feedback about?
This indicates a possible bug. I'll check that out.
Regards, Krzysztof
On 2013-10-05 18:44 +0200, Krzysztof Kosiński wrote:
2013/10/5 su_v <suv-sf@...58...>:
Lately, console is often filled with these types of warnings too:
WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4
I haven't attempted to figure out what triggers them exactly (node-editing path parameters of LPEs seems to be among the actions which tend to produce lots of them).
Is this something you'd like to have more feedback about?
This indicates a possible bug. I'll check that out.
My initial impression relating the warnings mainly to node-editing LPE path parameters was wrong: the warnings happen all over the place - even with shape tools editing regular shapes. There seems to be no obvious trigger AFAICT (based on casually monitoring the console).
Regards, V
On 2013-10-11 05:09 +0100, su_v wrote:
On 2013-10-05 18:44 +0200, Krzysztof Kosiński wrote:
2013/10/5 su_v <suv-sf@...58...>:
Lately, console is often filled with these types of warnings too:
WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4
I haven't attempted to figure out what triggers them exactly (node-editing path parameters of LPEs seems to be among the actions which tend to produce lots of them).
Is this something you'd like to have more feedback about?
This indicates a possible bug. I'll check that out.
My initial impression relating the warnings mainly to node-editing LPE path parameters was wrong: the warnings happen all over the place - even with shape tools editing regular shapes. There seems to be no obvious trigger AFAICT (based on casually monitoring the console).
This now has been filed as - Bug #1256597: several actions outputs to the terminal: "warning: invalid state when picking..." https://bugs.launchpad.net/inkscape/+bug/1256597
Regards, V
p.s. Personally, I won't further triage or monitor these warnings - for most of my local builds I commented out the relevant change from r12645, because the amount of identical messages on the console was too high and distracted from real errors.
participants (4)
-
Johan Engelen -
Krzysztof Kosiński -
Martin Owens -
su_v