On 12/7/05, Mathieu Dimanche <mdimanche@...> 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).
Inkscape. Draw Freely.