World: r3wp

globs => you mean in glass ?

yep, the low-level engine over which glass is done.


I was confirming that its a good and simple way to go forward for 
R3 too.

Didier, are you thinking of how QNX Photon worked? I can't remember 
exactly, but that sounds like what it did.

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

Demo of pixel accurate resizing.

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


Same as 210, except border sizes for each individual GOB is randomized.

Randomized to be different, but constant for each rect or to vary 
on the different sides?  It seems to be the latter...

I guess I'm asking if the variance I see on the various sides is 
an artifact of the resizing

the gob size is supposed to be nice like in 210, but the border moves 
in and out randomly per side per gob.

this is what you're working on fixing currently?

Cyphre is working on this, yes.

sorry, I should learn how to read stuff that's been posted already...

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons.

  ..... I am not sure I can understan, how it is done. Is another gob 
  used to define click-area?. Carl reduced VID to one-style = one-gob, 
  and it was clear it can't work for more complex style, you had to 
  "switch" drawblocks anyway. Now if I understand it correctly, we 
  are back to kind of  "border" aspect of R2? 


I still liked maybe more complex but also more flexible way of Gab's 
VID, where one style was compound of more gobs, if needed ....

you don't need another gob to define click-area. It will be probably 
done using a bitmap mask.

Also you can have more gobs in one style. But you do not need it, 
most of the time.

bitmap mask? Will not it be slow?

Pekr, after working with multiple GOBs for a single face, I think 
it's simply easier to just work with one GOB and a set of draw blocks 
on top of it. Otherwise you get many small parts.

Pekr - why slow?

Well, that might be psychological, but I always hated to work with 
"border" in R2. You have to count it into metrics ..... but maybe 
your model is different, than having border area ... but I can understand, 
that having shadow/glow to UI elements could be troublesome othewise 
...

the box model Cyphre is working on is unlike R2View, it's more similar 
to CSS.

why slow? I don't know. What's the bitmap mask anyway? Some low level 
C function? I thought that putting one transparent gob upon the drawed 
gob could be faster, as event engine simply flows event to particular 
gobs .... (but it would probably cost a memory, because you would 
need two gobs for one style)

re "Box model" ... good to know ...

You render all visible faces to a bitmap. Each face has different 
color. The you just read mouse coordinates and do a PICK on the bitmap. 
That way you know exactly where the event should end. That's the 
bitmap mask.

a bitmap mask has the advantage that we can define any shape, even 
counting in anti-aliasing for clickable area.

Thanks for explanation, Bolek, looks easy :-) The only thing I can't 
techically imagine is "you render" .... is it special added operation, 
or you just use already-somewhere-in-memory-rendered area?

hmm, those are low level changes, so Cyphre is doing it his own code 
branch, or does he have code synced with Carl?

sorry for so many questions ... I am just interested :-) I hope more 
guys gets interested too, and even join the testing phase and style 
creation process :-)

btw - what is the situation/plan with fonts? Initial (recent) VID3 
(View) font rendering was not sometimes too pleasant. Was it due 
to not so precise font metrics 'tex-size calculations, or was it 
due to not being able to use more advanced (licensed/patented) techniques? 
Is there any way of how to resolve this issue?

render - well, there are different ways to do it, you must ask Cyphre 
how exactly he's going to it.

Pekr, there are still options in the font rendering engine not exposed 
in DRAW. we need the host kit for that.

What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.

Pekr, re font rendering improvements....have a look at this famous 
article: http://antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION

Mcseem describes possible way we could try in R3 version but it would 
need some more expereiments.

that's a very nice summary of various font issues.

(regardless of AGG)

Henrik - any new screenshots to R3 GUI in the pipeline? :-)

Also - with the change to the "box model" and introduction of "material" 
system, will it be any easier to adapt the overall GUI look?

Not yet. Carl has entered the resizing discussion and there is not 
yet an outcome.

Materials system is being reviewed by Bolek. May need some changes.

Resize system has been worked intensely on by Ladislav and Cyphre 
for the past few days.

hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)

From my perpsective it is easy - we need resizing system, which just 
works. With RebGUI, I still had some issues even with simple GUIs 
....

I've not read the discussion yet.

I expect your world being private one right? No web-public output 
at least, so that we can at least passively read some discussions, 
and kind of "influence" it from here? :-)

yes, it's private

I consider bitmap mask as the  way how to detect click in non rectangular 
areas. It's probably how Flash does it as well. You cannot use alfa 
channel because in many cases you need transparent buttons.

The missing word in my sentence above is "best" - but how I think 
about it, the alpha channel could be used as well if there was some 
flag which would inform the engine, that it should not render the 
gob, but still use it to receive events.

Using the alpha channel with the visibility flag would save some 
memory in many cases.

using alpha would limit you to only 255 controls.

Bitmask or alpha channal would only be used where non-rectangluar 
areas need to be clickable, so that, Maxim, means they are handled 
on a per GOB or per-Style base, giving 255 controls per GOB or Style, 
not in total, at least that's my understanding.

ah ok, that makes sense, but then you are limited in that each gob 
has to fit within a rectangular area, and do 2 checks.  first on 
the area then on the mask.

Yes, point taken, but I don't expect those double check to be a big 
performance burden. First, it's still fast, and second, it probably 
is reserved for special needs only. Not every button with e.g. rounded 
borders needs to be detectable on a per pixel basis, often a rectangular 
region would suffix in most cases, I guess.

No it won`t be a performance problem for sure.