Re: "wxt on Mac": news

[<tim...@en...>]

> On Friday 30 March 2007 12:49, Timothée Lecomte wrote:
>> > On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>> >> So there is one remaining thing to try, but this will involve more
>> >> work on my part: changing the way wxt works on Unix and Mac and
>> >> arrange it so that the main thread runs the event loop while the
>> >> usual gnuplot command-line loop runs in the separate thread.
>> >
>> > Sounds to me that Cocoa is broken by design.
>> > Given this design limitation,
>> > I suspect it would be easier/better to use the gnuplot+gnuplot_x11
>> model.
>> > Instead of running wxt as a daughter thread, spawn a separate process
>> > for which it is the main thread.
>>
>> That's an option, with its own issues
>> (locating the executable,
>   should not be an issue on OSX
>
>> using an interprocess communication mechanism
>   already works on OSX for x11 terminal; this should be no worse

right

>
>> - pipes are not available on Windows
>   not relevant to OSX, surely?
>

My point is that I want to share code/implementation for as more platforms
as possible.

>> -, bottlenecks in this mechanism, etc.).
>   This one is a real issue, however.
>   One my linux machines, the wxt terminal is somewhat slower than x11,
>   and x11 is already limited partly by the pipe throughput between
>   gnuplot and gnuplot_x11.
>   The question is: would the slowdown due to limited pipe throughput
>   be additive with the slowdown due to using wxt, or is it partially
>   masked by it?  I.e. does the pipe transfer overlap with the execution
>   of drawing commands?  If so, then the additional slowdown due to
>   piping may be minimal in practice.
>

You're right, in the current situation of cairo performance, the
bottleneck would be the drawing. But the current situation is using only
software rendering, whereas Cairo can also draw directly to native
"surfaces" (it's what is done in wxt on Windows, and the rendering is
indeed faster than with linux, where the rendering is done purely in
software) and such a performance gain may put the pipe as the bottleneck
again.

But still, if it's really more practical to have a separate process, it
may be worth it.

>
> Other possible solution:
>
> Some quick googling led me to some pages that seem to imply that
> apps have a choice between using carbon or cocoa.  If this problem is
> due to a mis-feature in cocoa, do we have the option of using carbon
> instead?  (I've never done development on OSX, and have only a vague
> idea what the difference between the two is, other than historically).
>

Unfortunately, _wxWidgets_ already uses both, and apart from dropping
wxWidgets, I don't see a solution (FYI the MacOS port of GTK+ seems to do
the same, i.e. use both Cocoa and Carbon for fine-tuning).
Cocoa is object-oriented, written in "Objective-C", whereas Carbon is pure
C. The object-oriented approach is supposed to be more adapted for GUI
development.

Best regards,

Timothée