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
