World: r3wp

Is the AGG cache an enhancement ?

*AGG cache stack

doing 2D using  3D hardwar stacks generates a lot of problems due 
to the antialiasing and mipmaping manipulation ( and  drawing text 
without true font but with mipmaps  provide you no gain the card 
will not use it's fonts acceleration then)

cache are always a good thing for repetitive task if you draw use 
is to draw 1 square or 1 circle or 1 line of texte will you don't 
need a cache buuuuuuut

if you do  a document rendering like area-tc with alot of  time the 
same calls over and over again then you see the obvious optimisation 
brought by a cash

i hope with the cash we tends to a more extensive use of AGG and 
a less anecdotic use of this marvelous fantastic powerfull tool (aGG)

he needs cash, but it's cache

:-)

http://www.presence-pc.com/tests/2d-windows-gdi-23257/10/for the 
article

6 am i got a heavy day yesterday and i take some time before going 
to work to be tuned ....

multiple draw blocks per styles it's like a stack systems ?  you 
could influence a layer of graphical contents without touching the 
other block

?

different states like hover/pressed, etc could be described in different 
states, allowing us to switch between them quickly.

i like that idea ... it will introduce much more flexibility ... 
 and allow something link  annimations without having to redraw all 
the blocks only drawing the blowk that have changed

been doing this for years  ;-)

so the draw blocks would get interactive ?

Not sure, there is one state at a time.

you could switch them based on some sort of finite state machine.

I don't think it's the purpose of states

maxim yeah but push is not optimal  in rebol 2 bloacks you think 
only the pushed is drawn but the show call force the redrawing of 
all killing perfs

ok it's too early to speak english for me i need a coffee and a proper 
wakeup

i'm leaving i will try to get around at a more suitable time for 
me ...

graphic engines redraw everything at each redraw, even in 3D.   this 
is because of transparency and depth sorting.

see you and i will keep watching the gui part

by redraw, I mean the rasterizing... which is usually where most 
of the processing occurs.

http://rebol.hmkdesign.dk/files/r3/gui/220.png


220 to 225 shows the resize engine in use with globally set borders 
with quite good pixel accuracy. the border style should be possible 
to set globally according to cyphre in a similar way as in VID, of 
course without the artistic limitations of VID.

btw, you couldn't access the gif image, because my cheyenne server 
had decided to stop for some reason.

Eh?  I must have retrieved it from cache then

trace.log nothing??

not cache, as it stopped after you fetched the gif.

Very nice Henrik. Thanks for keeping us updated.

base-url: http://rebol.hmkdesign.dk/files/r3/gui/
img-url: func [id] [rejoin [base-url id %.png]]
ids: [%220 %221 %222 %223 %224 %225]
imgs: copy []
foreach id ids [repend imgs [id load read/binary img-url id]]
cur-id: first ids
show-next-image: does [
    cur-id: select join ids first ids cur-id
    set-face f-img imgs/:cur-id
]
view layout [
    f-img: image (imgs/:cur-id)
    btn "Next" [show-next-image]
]

http://rebol.hmkdesign.dk/files/r3/gui/225.png
http://rebol.hmkdesign.dk/files/r3/gui/226.png


First integration test of the new resizing scheme. It looks much 
more solid and accurate, but there are still a few bugs (the partially 
blanked button in 226).

Styles will require some modifications to work with the new scheme.

Looks very nice Henrik.

Henrik - what do you mean by "partially blanked button in 226"?

the bottom of the upper left button is missing

WAHOUUUU !!!!!!! REBOL GUI START LOOKING LIKE SOMETHING A PRO COULD 
SELL !!!

still funny, as the skin is still about 5 minutes of work.

It seems I posted the wrong links. I meant picture 226 and 227, not 
225 and 226.

so the error that Pekr was looking for is in 227.

I thought I just wasn't perceptive enough to notice a subtle error 
in 226. I can see the problem in 227. :-)

Not complaining though. It looks great.

there are still a few bugs (the partially blanked button in 226

 - yes, that is a Draw bug as it looks. BTW, it has nothing in common 
 with the new resizing scheme, the above new resizing scheme test 
 just exposed the bug

twitter: Successful branch: Cyphre can do R3 builds now, including 
native graphics extension module.

Is this the hostkit ??

yes, there are a few internal releases of the host kit.

Some resulting exes:

07/10/2010  12:45 PM           267,776 r3.exe
07/10/2010  12:46 PM            28,672 r3core.exe
07/10/2010  12:34 PM           393,216 r3lib.dll

You can build an R3/Core without AGG.

The current hostkit zip file size is 773 kb.

The structure is squeaky clean. Even I can figure it out.

internal releases meaning a restricted release

the POSIX part is not complete and Robert has some compile problems.