> This is very cool. I'm sold on it!
Glad you like it.
> However, I did note that when the page is crowded, the response time
> gets very, very slow. The constant re-rendering will have to be
> replaced with a backing-store setup, so that most redrawing can be
> done by copying blocks from one pixmap to another, instead of calling
> all of the rendering routines.
I was thinking about a pixmap (or group in cairo speak) of the fixed items, and
then let the tools draw their stuff on top. I am now trying to understand all
the eventmode stuff.
One suggestion I can think of is to arrange everything in a somewhat more
object oriented way.
So that instead of a short event_mode, you get a pointer to a struct (cf. c++
class) with some functors to specific functions (cf. c++ virtual methods).
Something like:
struct {
void (*draw_tool)(.....)
void (*compatible_function)(int function);
int (*dispatch)(int function, short value, int x, int y);
void (*destroy)(void);
} xc_tool;
and then replace
eventmode = ARC_MODE
with:
eventmode = xc_arc_tool_create(int x, int y);
This way one could get rid of all the switch statements and have more
'separation' between tools. I implemented an eventmode myself, but I felt like
playing with a house of cards. Changing a little thing could collapse
everything.
However this is just my limitation. I am used to programming in an object
oriented way, ie. Keeping all functions related to an object together. Xcircuit
uses more of the other paradigm: Keeping the same operation on all objects
together. (I cannot remember the proper names for the paradigms.)
Any ideas about such a change?
Erik.
_______________________________________________
Xcircuit-dev mailing list
Xcircuit-dev@opencircuitdesign.com
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
