12:06 p.m.
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
[1] https://bugs.launchpad.net/inkscape/+bug/850992
1:15 p.m.
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
4:35 a.m.
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
4:52 a.m.
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,
7:12 a.m.
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
5:58 a.m.
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
9:10 a.m.
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
10:43 a.m.
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,
11:17 a.m.
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.
2:56 a.m.
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:/s...
3:17 a.m.
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:
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
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
1:31 a.m.
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:
> 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
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
1:44 a.m.
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
12:09 p.m.
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
8:18 p.m.
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.
3469
days inactive
3533
days old
inkscape-devel@lists.inkscape.org
14 comments
4 participants
participants (4)
-
Johan Engelen -
Krzysztof Kosiński -
Martin Owens -
su_v