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

Reply via email to