GNOME.org
 

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



On Thu, May 23, 2013 at 1:50 PM, Donn <donn ingle gmail com> wrote:

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.
Store the matrix, convert the mouse pointer to canvas space (or polygonspace), not the other way round. 

 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)
If you can not be sure what your target devices have as backend (not to even speak of implementation specific stuff) set a lower-border and develope against that (i.e. software rendering) 


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?


‘9’
Sorry, you will have to figure that out on your own - I am not sure that it is possible at all - my familiarity with cairo is limited to a quite small subset of API calls (mostly polygon and matrix stuff, nothing blitting related (yet)). 


 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.
If your clouds move you got some kind of clocking don't you? If so then just store all your events into static/global vars (yes, that's ugly - find a better solution - hint: user_data) and do the checks in a clocked interval (reminder: g_timeout_add is not very suiteable, as it is a "round about" timer) 


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!



Good luck and keep going.
Note: If you are going for such a complex widget - if you want to share it - it is usually "better" (as of everybody will be able to use it) if you write it in good old C. VALA after all compiles to C, but well .. code compiler gibberish all over the place. 

Bernhard
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]