bulia byak a écrit :
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
I just tried that, and you're right, it's really cleaner and it works well, it's in the new patch. But think I still need to modify every context, for each start of a GDK_MOTION_NOTIFY requires a desktop->namedview->reset_snapped_visual_feedback() to downlight everything.
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. I can be a whole HighlightGroup (one per Snapper), or just some HightlightItem in it (the HighlightGroup for the grid could have 4 Items in it at frame f, 2 lines and 2 text-hints, and just have 1 line and 1 hint at frame f+1 so the highlightmanager knows he must update the group (delete 2 items), and the 2 remaining items if they changed and need update.
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.
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.
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.
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