On 12/7/05, Mathieu Dimanche <mdimanche@...8...> wrote:
>Well, why do you need to downlight on each MOTION_NOTIFY? This
sounds
>unclean and may even slow it down, since motion events may come very
>fast. Can you try to do that in Snapper instead? I think if you add to
>Snapper::vector_snap not only highlighting when there's snap but also
>downlighting when there's _no_ snap, it would take care of this
>automatically. Tool contexts that do snapping already keep calling
>vector_snap while the mouse is being dragged. Then the only situation
>when you have to downlight artificially is when you snapped something
>and released mouse without unsnapping it, and that's what the
>event_context release handler already takes care of.
>
>
I didn't really mean downlight _everything_, but erase the hightlights
that were ON and now OFF.
Sure. But this is not what I was talking about. My point is that
downlighting can only happen in the same situation when some
highlighting (i.e. snapping) might happen, and therefore it makes
sense to do both highlighting and downlighting in one function - the
one which various contexts call to get snapped coords. Those contexts
or situations where no snapping is done would not spend time trying to
downlight anything. So I propose to add a call to downlighting to the
same place as highlighting, that is, Snapper::vector_snap (or whatever
is its currently named after Carl's changes) and remove any downlight
calls from contexts. Does that make sense?
my idea was to make the snapping objects tell the highlighting
manager
what they needed to be shown as highlighted, so the manager gives them
an HighlightGroup to fill with graphical HighlightItems. If the group
already existed in the previous update phase, the snapper updates the
infos of its previous group. If no group existed, the highlight manager
creates a brand new one. The only thing needed is then to call some
highlight manager member before every redraw to mark "old" (previous
frame) groups for deletion, let them be filled/updated by snappers (or
other objects that want to highlight things) during the motion_notify
event and deleting the groups and items still marked before the final
highlight drawing.
Right, except the Snapper::vector_snap has no idea of motion_notify
events. It's just called whenever it's convenient for the contexts. In
other words, it's a call to snapper that causes high/down lighting,
not any motion_notify by itself.
By doing this, I intended to separate the snapper objects from the
highlight objects so the highlight manager could be separate from
snapping, to allow us (maybe in the future) to highlight things that are
not snapped. I didn't want any drawing management to be in Snapper
objects, so HighlightItems and HighlightGroups are here to hold the
informations for highlighting a specific object.
Sure, this makes sense. Just also separate highlighting calls from contexts :)
About speed, I think this method could be efficient because if
Snapper::vector_snap does the downlighting, then for every frame to
draw, all snappers must tell the highlight manager the current state of
every graphical highlight object (line/dot/etc...) they contain, either
now (during vector_snap) or keep this state so it can tell this back to
the highlight manager when this one wants to draw everything. I didn't
want this state to be in the Snapper object but filled in a group by it,
so not only snappers can highlight things, and I don't like the idea of
a snapper member doing "making really sure this line of mine is to be
OFF the highlight layer for this frame (...just in case)", because it
means every Snapper will have to check the status of all its
highlightable components.
No. Snapper does not have to know anything about what's highlighted.
It just calls a generic "downlight everything" function on the
highlighting manager, and that's where it will figure out what's up
and what needs to be switched off.
I'm not sure I'm clear enough and I probably need to do what
ScislaC
told me yesterday :)
[08:12:39] <ScislaC> mtou: you might want to look at Bulia's outline
view code when you want to highlight the objects, it's probably not too
far off in some ways
No, outline mode is entire in the arena layer, you don't need that. If
you need to highlight arbitrary paths, you'll need to look up how
canvas items for paths are created by the Pen tool (those green and
red temporary curves).
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org