Hello Erik and Tim, Nice work!
I integrated the Cygwin compile patches I had from the 3.8 branch. I was able to compile with cairo on cygwin. I like the very nicely anti-aliased figures and text. I had to substitute Arial for Helvetica using ~/.fonts.conf, since Helvetica is not available in TTF under Cygwin. Incidentally, the TCL and TK auto detection does not work under Ubuntu. It seems TCL_LIB_DIR and TK_LIB_DIR are not set by the tclConfig.sh and tkConfig.sh, but configure.in seems to assume these variables would be set. The usable variables seem to be TCL_LIB_SPEC and TK_LIB_SPEC . Thanks, Satya ~/.fonts.conf: <!--?xml version="1.0"?>--> <!--DOCTYPE fontconfig SYSTEM "fonts.dtd">--> <!-- ~/.fonts.conf for per-user font configuration --> <fontconfig> <match> <test name="family"><string>Helvetica</string></test> <edit name="family" mode="prepend" binding="strong"> <string>Arial</string> <string>Helvetica</string> </edit> </match> </fontconfig> On 5/17/2014 9:46 AM, Tim Edwards wrote: > Hello Erik, > > XCircuit version 3.9 is up on the opencircuitdesign.com site! > >>> 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? > > I would avoid a major paradigm shift at first; it's a good > long-term project, but it's going to involve a lot of coding. > It would probably be a better first step to see how much of the > redrawing can be replaced by copying blocks out of the pixmap. > > The speed of rendering, though, may be a problem given that, for > example, zooming in and out always requires a complete redraw, and so > there's no getting around the fact that an entire screen redraw needs > to be fast. > > It's possible that I'm missing hardware acceleration. I'm not sure > how to know if I am or am not getting slowed down by software > emulation, and I have not yet investigated that. > > ---Tim > > +--------------------------------+-------------------------------------+ > | R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com | > | Open Circuit Design | web: http://opencircuitdesign.com | > | 22815 Timber Creek Lane | phone: (301) 528-5030 | > | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | > +--------------------------------+-------------------------------------+ > _______________________________________________ > Xcircuit-dev mailing list > Xcircuit-dev@opencircuitdesign.com > http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev