On Sep 21, 2010, at 11:12 AM, Chris Albertson wrote:

> 
> On Sep 21, 2010, at 6:01 AM, Kuba Ober wrote:
> 
>> After looking at the ghostscript code, it seems that the gs executable is 
>> used  a separate process. I presume it would make sense to rework this to 
>> use the shared library? See <http://pages.cs.wisc.edu/~ghost/doc/svn/API.htm>
> 
> Using a separate process may allow some degree of parallel processing.  Don't 
> forget that most people today have at least dual CPUs and many have quads or 
> more.  It is common today to use threads in programs like this.     If you do 
> bring GS into the process maybe keep it a thread.   You'd gain a little that 
> way in not having to wait for a process creation and the communication is 
> faster.

Chris -- I agree, it'd work in a separate thread.

QImageIO doesn't know about threads: it's a blocking system where you call the 
load function, and eventually the function returns, giving you an instance of 
QImage; perhaps a null one if something went wrong. What you do, then, is kick 
image loading into a separate QObject, invoke it via a slot, and then act on a 
signal coming back when the image has been loaded. Once you use QObjects, it's 
trivial to create a QThread, and move the QObject to a thread and voila. Qt 
handles inter-thread synchronization.

Drawing area resizing implies that the QImage has to be reloaded -- once 
loaded, a QImage has fixed size. But I can do it intelligently such that the 
image file won't have to be re-read from the disk, I would use gs API's display 
functionality, etc. Thanks to Qt's architecture, it's pretty easy. Probably 
it's more wordy in English than in code :)

Anyway, I see that the Qt port has chances of adding lots of functionality to 
the code that would be otherwise fairly menial and unfunny to do. Examples: 8 
bit text encodings are all trivially handled within Qt, you deal with QStrings 
until it comes to do the I/O and then you simply chose what to transcode into 
(Latin-n, UTF-8, something custom, blabla). Generating PDF output is also 
trivial. It's also simple to vectorize system fonts so that they can be 
imported into xcircuit-compatible lps font files.

Cheers, Kuba
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev

Reply via email to