Re: GTK+3 - A common event handler - Gone OT into cairo and draw territory

[Donn <donn ingle gmail com>]

Thanks for your thoughts, I have pushed my luck and replied :)

On 22/05/2013 17:18, Bernhard Schuster wrote:
> If you compose your stuff of polygons (which I am pretty sure you
> do), there is pretty neat math to check if your cursor is in or
> outside of a polygon (for low vertex count polygons, for greater
> numbers you need to calculate a boundingbox that is fixed for at
> least a few frames). This actually detaches the position-checks from
> the drawing event. A somewhat-model-view approach.
I have actually used that point in a polygon algorithm. The problem is
the matrix transforms and the disjunct between the mouse coordinates and
the coordinate space within which the target shape exists.
 The device to user and back stuff.
I don't know how to get the user_space without the Cairo Context and
this comes around to the catch-22 again: You only get a Context in the
draw() signal handler.

> whole thing also depends on your backend. If you got a decent (
> OpenGL 2.1 or newer ) video card it is not really sane to calculate
> dirty regions and redraw them (especially if you got a lot of items
> floating/hanging around).
I'm not sure what 'backend' my GTK library is using. I'm fairly sure
it's not drawing Cairo paths and fills directly into GL - I reckon it's
still CPU bound and it's filling memory arrays which are then being
handed-down to the lower voodoo which mysteriously gets it to the
screen. i.e. it's texture maps onto GL rectangles managed by Unity (I'm
on ubuntu atm)


> > The thing is - *if* the canvas has *not* changed, *but* I have a
> > tool or icon on the topmost layer that moves (I call it a sprite)
> > by a few pixels, then it makes more sense to do a small blit of
> > the old background and draw the sprite in a new position - rather
> > than drawing all my canvas objects again just so I can draw the
> > sprite in a new position.

> That means you need to walk your tree, check all items bounding
> boxes and redraw all which intersect with the boundingbox of the item
> moved (in the old and new position, otherwise you'd get artifacts)
I see what you mean. But how?

Think something like Flash or imagine a complex Inkscape drawing that is
animated (See * just below) ...
 You may have a dozen sections of complex vector shapes in many layers 
beneath the bounding-box of the sprite. Gradients, paths, fills, stuff 
under multiple transforms.
 I do not see how vector construction commands like the ones Cairo uses
can be made to draw *only* that small region.

 It's really a job for a block-copy kind of blit thing. I have asked
over on the Cairo list for such help, but there's little response. I
have been told to look into patterns and surfaces - so that's where I'm
heading. Slowly.


* Picture:
 A blue sky gradienting to white. A bunch of cloud images superimposed,
their alphas show the background. The clouds stack above each other -
many layers. They move left to right, some the other way.
There's an animated glowing Sun that rises behind them but in-front of
the gradient sky. Winter leaves blow in path-following spirals in the
foreground.
We pause the animation and are editing. A small 32x32 eyeball icon
appears at my mouse when I hit space. It intersects with:
1. a bit of the leaf vector - which is itself a group of many smaller
shapes and fills to form the leaf.
2. several layers of bits of clouds
3. some section of the sun -- also a group of child shapes. For e.g. the 
'rays' would be triangles repeated under a rotation transform.
3. some section of the gradient sky.



> Keep trying, there is always that "reading-foreign-code" barrier -
> at first it sometimes looks all gibberish :)
Boy, you said it! I shall persevere.


> Makes somewhat sense, you are expected to pass a class instead of a
> bare function. You can then stuff all your data into that class, the
> only limitation in comparsion to C is, that your class _must_ contain
> the handler too.
And thanks for this!

\d