On Thu, 2007-11-01 at 09:39 -0700, Steve Meier wrote: > There is no implicit requirement for the library to have an > understanding of the rendering engine. Nor is there a requirement for > the library to deal in any other unit then real world units. All the > library has to have is pointers to drawing functions in the application > and that those application drawing functions would take care of zooming > and panning.
Sure, I suspect we're not differing too much in opinion here, but perhaps terminology. A "redraw" vs. "changed notification" callback might actually do the same thing in gschem. Calling it "redraw" just implies it must redraw. I think this mechanism is good for drawing updates related to object changes from within libgeda (as side-effects of gschem induced operations etc..). I don't think there should be _any_ explicit redraws in gschem based on knowledge we just asked libgeda to manipulate something. Gschem should only self-redraw for events intrinsic to gschem. IE. X11 expose events, zooming and panning. gschem should not need to ask libgeda to call into gschem's redraw functions in its own behalf. > It also seems to me that there are ways to reduce the amount of > redrawing work. Without the viewer application having to be directly > manipulating the libraries data structures. Yep, and its being worked on. (At least, the stuff which is breaking com positing). My fixes so far are to draw into the back buffer, and will invalidate a region of window corresponding to the extremes where drawing have occurred. This should happen after all updates are made to the back buffer (by some definition of "all"). If you can suggest any further improvements, let me know - as I've not dug too deeply into this yet. > The viewer could have a list of drawing primitive objects, lines, > circles, boxes, text etc that it builds as the page draws. The viewer > wouldn't have to know which of these lines belong to which complex > object. If it wanted to pan or zoom it would just use its list of > primitives. True, and to be honest, some form of state cachine in the "view" portion of a MVC arrangement is inevitable anyway, so that gschem knows what portions of the screen were _previously_ used, and need redrawing after an object change. (Unless each "changed" type notification sends a before / after state). > When the user wants to sellect a group of things and drag them then its > important that the select box real world dimensions are sent to the > library or the location in real world coordinants of the pointer are > sent so that the library can determine what has been selected and then > when they are dragged the translation motion in real world coordinants > are sent to the library. The library then should again have a function > s_page_draw_selection_list...... again this new list of primitive > objects could be retained by the viewer for rappid redrawing. Selections are tricky, and I can't remember what my conclusions (if any) on this topic were. I'm of the opinion that no backend change should be made until a move / copy operation completes, although those operations can / should use libgeda primitives where useful. Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
