On Sun, 19 Dec 1999, Andreas Beck wrote:

> > Incidentally, I'm -going- to write a scale-target for GGI.  Any
> > suggestions on what I should base it on?  Currently I'm looking at palemu
> > but I don't like it.  
> 
> Depends on how you want to implement it. There are two conceptually different
> methods: 
> 
> 1. Scale-while-drawing: For that I'd use the "sub" target as a starting
> point. This allows to kind of "accelerate" the drawing (by hooking into
> all drawing functions) and will get better results for stuff like CAD, 
> but can cause funny effects with read/modify/write style access.
> 
> 2. Draw-in-membuffer-then-scale: The tile or palemu-target might be a good 
> base for that. A nice thing would be, if we could integrate it with the
> multi target, or at least allow its semantics. It would be nice, if one
> could do something like:
> 
> GGI_DISPLAY="scale:(memory:-scale 2:kgi:-scaleto 1024x768:X)"
> 
> Which should use the memory target as "primary" drawing target that e.g.
> gets set to 320x240 by the application. This output is then scaled by 2 
> and placed on a kgi visual and scaled to 1024x768 and sent to X.

technically it does 2 at the moment....  I suppose one -could- do 1 as
well but I haven't really looked at it yet.  Actually, now that I am
thinking about it it would be dreadfully easy to code it to do both...

I posted some code for this a ways back - it uses a lookup buffer to find
[X,Y] positioning and is -very- fast.  I implemented it into d1x and now
can have descent looking like 320x200 at -any- resolution I want although
I typically run 640x480 for it.

It isn't really 'scale by X' specific or anything.  Actually it's designed
for scaling from [width X height] to different [width X height]

As soon as I can successfully do a 'cvs update -PAd' without timing out
I'll pick it up.  (no idea.  My ISP seems to be having a problem with
this).

G'day, eh? :)
        - Teunis

Reply via email to