World: r3wp

i see that some people recommend that your GUi should run in a separate 
thread from the rest of your application so that while's it's busy 
doing things, the GUI still remains responsive.  How can we apply 
that to R3?

I suppose the event model that Carl talked briefly about could rectify 
that, so there would not be a need for threading.

can anyone explain why there is a 'MOVE event every second when we 
have a gob! window open...  ?


I'm guessing its for blinking type handling.... but it should have 
its own type.  This also occured in R2 and its extremely annoying 
when handling events.

is the gob/image parameter supported in A107?  I can't seem to make 
it work...

gmask: make gob! [image: bmask]
gmask/offset: 30x0
gmask/image: bmask
probe type? bmask
probe gmask

== image!
== make gob! [offset: 30x0 size: 60x60 alpha: 0 image: none]

weird.  maybe the image gob type has been dropped?

Maxim, I have no idea whether it's related, but there is currently 
an issue with TO-IMAGE.

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

henrik, ok, in any case, we can use them within a draw block, which 
isn't that hard to do anyways... in the meanwhile

the issue is set to be solved in this week's sprint, by cyphre, but 
we'll see if he makes it.

ok well... I'm getting an assertion failed #1207 error crashes with 
large blocks... using to-draw on a large block closes R3 without 
any warning!

actually, its other series funcs which close rebol unexpetedly.  
  


WRITE and MOLD both have closed REBOL on that large draw block.... 
though strangely, the file is properly molded and written to disk.

actually, its the  TO-DRAW function which kills Rebol.

will reduce the problem to a reproductible crash test.

btw, the crashing draw block currently is ~8000 lines long.

Maxim, gob/image  is disable currently in the hostkit...I plan to 
get it back to work this week so you can expect it in the next releases.

also it would be good if you could trace that larger draw block crash 
or at least reduce it to smallest possible test case.

yeah, I was thinking of doing another test run... the current generating 
script is pretty convoluted as it goes through a complex liquid dataflow 
network to be built.

right now I'm busy integrating OpenGL within a gob!  :-)

a question... is there a single place where a gob is destroyed (maybe 
a callback or some method) within the host-kit?  just so its more 
invisible, when I need to detach a gob from the OpenGL rendering 
context... at this point I have all I need to build an OpenGL gob.. 
but nothing to get it automatically cleaned up.

GOB is 'destroyed' by GC AFAIK so you shouldn't rely on that event 
imo. I don't know details of your implementation but making separate 
OpenGL context for every GOB doesn't seems to me as a good idea.

another question.  if I have a region of ram which contains rgba 
pixel data as an array.    what is the function I need to call within 
the compositor::cp_process_gobs() func so that I can copy that array 
within a gob's pixel buffer?


I've been running around the source and its a bit complicated... 
there are so little comments in the agg code... I'm not sure what 
does what.


I was thinking that the clue lies somewhere in the undefined code 
within 
case GOBT_IMAGE:

the gob will act as a container for an OpenGL context (and viewport).


so a single gob! will store the whole 3d scene, not just a single 
poly/shape.   I guess I'll have a command block similar to gob!/draw 
 to define some aspects of a 3D scene (though not everything... since 
3D is pretty heavy... probably things will be loadable from ram and 
disk)

case GOBT_IMAGE: is a place where the gob/image content is rendered..as 
I said this code was disabled when Carl updated the hostkit. I'll 
be updating that part this week.

but is the code for copying over image data to the compositing buffer 
basically there?

mainly:
	ren_buf m_rbuf_img;
	m_rbuf_img.attach(GOB_BITMAP(gob),gobw,gobh,gobw * 4);
	agg_graphics::pixfmt pixf_img(m_rbuf_img);
	[...]
	m_rb_win.copy_from(m_rbuf_img)

yes

ok, I'll fiddle around until it works  :-)


I know that all of what i'm doing is currently subject to being broken 
at each release, but I took care not to mix my code within any of 
the extensions, so its pretty easy to merge and adapt with your next 
releases.

my goal is to allow an dynamic linking of any external gfx engine 
within the current system.   hopefully DirectX, Cairo and ImageMagic 
integrations will also be possible, but I have no idea about their 
API so it might still be a pipe dram at this point.

Yes, this is not so easy to do as you need to always manage the window 
differently for almost every gfx system. I have in works AGG accelerated 
using OpenGL using one trick which makes things much easier and still 
pixel precise. But I need to try convert the pure c++ prototype code 
into the Hostkit first to see how it behaves in 'real world' usage 
cases...

the question I am asking myself is if I can have both an OpenGL and 
Direct gob! in the same window  :-D

Direct = DirectX

I don't think so..but maybe there is some 'hack' for that. Anyway 
not sure why would you need such setup.

I am just wondering... really.

OpenGL and DirectX can give you different rendering capabilities, 
so I think there is nothing wrong with having both in the same window 
for comparison side by side.

I have added hooks for Cairo and Image Magic too.  (though they aren't 
implemented in any ways whatsoever).

one of the strengths of image magic is that it can render using DISK 
memory.  which means that you can render images larger than your 
ram.  I am done a few tests in the past and ended up merging 20GB 
of images into a single render.  a part from it taking 30 minutes, 
it all went well, and the quality is fabulous.

it has a selection of ~ 10 filters, and it can render at any bit 
depth, as well as supporting all image formats known to man, and 
even a few video formats too.

Max - you've got Carl's answer in R3 Chat re modification of GOBs 
- it is no go .... Carl asks what you need it for ...

funny while doing tests yesterday, I realized it was still allocating 
only 64 bytes (based on the pointers) and I realized that I was going 
to corrupt ram... so I changed the system.

Does r3-gui.r3 run on core a107?

I'm getting an error.

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: %shape.r reason: none

never mind ...core...I would need to compile host kit

is there an available host kit version around? Just to play around...

yes, check the downloads directories

pre-compiled? I only see the kit.

Links were posted in the host kit group ... check them out

Just wanted to show what the GUI looks like without the box model:

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

And with the box model (panel skin was reset by this action):

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

it's very grey ... henrik ... I mean its looks likes an old movie 
the effect are cool but because they are grey over grey we don't 
notice them ...

completely missing the point, as usual.

the effect are cool the overall thing is  grey what i'm missing ?

Shadwolf - you are missing the fact, that 1) it is not final skin 
2) anyone can create alternate skin 3) Henrik just pointed out there 
is some difference, when box model is used ... :-)

The skin work is minimal, as there is only enough done to work the 
material system into the GUI.