[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: WMF support
From:       shaheed <srhaque () iee ! org>
Date:       2001-02-09 21:33:16
[Download RAW message or body]

Hi Dirk,

> Why don't you base your work on the current QPPainter design, as follows:
>
> - you define a set of basic graphics primitives (possibily somewhat higher
> as in the current
>   QPainter, e.g. the Postscript render primitives (see gnome-print))
>
> - any backend can implement these primitives, as long it is able to do it.
> - there should be a generic renderer, which renders to a bitmap/pixmap, any
> backend should be at least be able to output a  pre-rendered bitmap
>
> - if you define extensions, you also define "capabilities" i.e. constants.
> - an graphics client can query a given backend, if a given capability is
> supported
> - if it isn't supported there are two ways:
>
> - it can draw with "lower" primitives
> - it can try to find another backend, which implements the needed
> functionality
>   this backend should be rendered into a bitmap/pixmap, which is then
> output to target
>   backend.

This is sort of how the code I wrote works. It defines a (currently very 
basic, and probably quite broken) "drawing context", and then makes this 
visible to each drawing primitive. This sort of merges the 
QPainter+QPaintDevice into one, which (I think) has the great merit of hiding 
all the pushing and popping of state that QPainter (and other bitmap focussed 
drawing classes seem to use).

This makes it easier to produce modular code for the cases where it is 
important to preserve the vector nature of the data. AFAICS, a QPainter 
approach seems to throw away all the vector-style info, and then needs to 
reconstruct it for this case. On the other hand, I think that vectors would 
be easy to map down to bitmaps as required.

My progress came to a halt when I tried to understand the primitives in WMF: 
I did not spend the time to understand all the intricacies of bitblt etc. 
However, someone who does should be able to complete kwmf easily (the main 
hole I am aware of in the current design is that subclasses probably want to 
be able to provide thier own subclass of DrawingContext...abut this is a 
SMOP, I think).

Does that make sense?
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]