World: r3wp

this is a very serious bug, cause it means that any draw block can 
crash at any time.

(if it is constructed dynamically)

so Linear fill is a condition for this bug, for sure.   


But its an internal issue where the size/complexity of the draw block 
will trigger it.  


note its not just a question of having a big draw block, I think 
it has to do with the block being a specific size (prime numbers, 
for example)

I will try to get Carl into fixing this for 2.7.8

this is a serious Draw flaw, its totally unpreventable, undetectable, 
& unpredictable.


adding / removing items to the block will trigger the crash sooner 
or later.

the only constant being that the more   [ fill-pen linear ]    items 
in the block, the sooner it crashes... at some point, (depending 
on your block), it crashes at the very first draw.

it seems using 'CLIP in the DRAW block is the root evil  in  previous 
crash.

anyone else found that CLIP was buggy?

Well, if you are able to make at least script that is able to crash 
(even randomly) I can test it here on external agg dll DRAW emulator 
to see if the porblem is in AGG code itself or if it is on the rebol 
dielaect side.

cyphre, here is a script which crashes. 


http://www.pointillistic.com/open-REBOL/moa/files/draw-clip-crash.r

very unstable, sometimes it crashes, sometimes not

yep.

did you try running with the clip  commented?

(as per the notes in the header)

yes with and without it

and it does it crash for you without clipping?

no it doesn't crash without clipping

ok thanks... gives more strength to my tests so far.

For what are the clippings used ?

I mean when are they emitted ?

so far,


fields: clipping text to field area (which can be smaller than the 
field itelf.

frames: clipping contents to frame bounds (just like faces in R2). 
this allows us to scroll frames within frames.


for frames the clipping isn't something I can ignore  it will have 
to work somehow.

hum  steeve did you try in 2.7.6 or 2.7.7  (SDK or full release view)?

I just updated the script so it crashes more frequently on 2.7.7. 
 the old one, it seems didn't crash for Carl !


this new one just kills view without a single refresh on my system.

curiously it can draw once in 2.7.6 SDK rebview.  put clicking on 
it ... BAM.  (on my system at least).

NEW bug.. (but not a crash)


using vectorial fonts with text ending in spaces, corrupts color 
transparency of any following draw  element !!!

example script:
rebol [
	title: "Vectorial text corrupts transparency"

 note: "bug occurs only when text ends with one or more spaces!!!"
]

myfont: make face/font []

; COLOR IS TRANSPARENT
box-bg: green + 0.0.0.128

view layout [
	box 350x50 effect  [ 
		draw [
			font myfont
			
			 ;draw crosses
			line-width 1 
			pen blue 
			line 10x29 109x05 
			line 10x05 109x29 
			line 110x29 209x05 
			line 110x05 209x29
			
		    line-width 2 
			pen 0.127.0 
			fill-pen box-bg
			box 10x05 109x29 3 
			
			line-width 0
			pen black
			text "1    " 47x07 vectorial
			;line 0x0 0x0
			
			line-width 2 
			pen 0.127.0 
			;---------
			; following color alpha is WRONGß
			fill-pen box-bg			 
			box 110x05 209x29 3 
			
			line-width 0
			pen black 
			text "2" 154x07 vectorial 
		]
	]
]

UPDATE on clipping crash..   


using CLIP NONE , seems to be the definite cause which makes AGG 
crash in my tests.

Instead of CLIP NONE, does it work if you CLIP 0x0 350x50 (in effect 
no clipping at all)?

nope....

that solution is exactly what I tried and it worked for awhile...

then BAM... a crash... so its back to square one... linear fills, 
when clipping, just crash AGG at some indefinite point in time.

the above text bug is also pretty weird  :-)


I discovered it when I attached a field to a label and another control 
would change colour as I typed!  :-)

wrt clipping crash..... unfortunately I've had to remove all clipping 
for now... this complicates things A LOT  .

hence delays in my release

Are there any particular instance where OFFSET-TO-CARET will return 
NONE, even if the face has text?

oh, it seems to be when FACE/FONT is set to NONE. Nice to know.

Maxim, the first bug which crashes looks like DRAW dialect parser 
related as I tried it here with my debug library and it doesn't crash 
the agg engine itself. Unfortunately I can't test the original R2 
dialect part here.

The second bug with empty space in vectorial sctring is a side-effect 
of  one older known bug and I have already a fix for this one. I'll 
ask Carl if he can add that fix to the next R2 release.

you should get this info to Carl, so that he knows where the bug 
might be :-)

... I mean - the first one :-)

yes, I sent him a message on R3 chat.

thanks.

I suspect the CLIP bug could be the cause of large R2/View apps crashing.

I would definitely appreciate those View bugs being fixed.

Once again I come to the Gurus. My app selects a folder then goes 
off and processes files. Is there any way to interrupt that process 
if a user wants to?

While you process files you could check a global variable stop-me 
if it's true and if so, stop processing files. Then all you have 
to do is add a button to your GUI that sets stop-me to true when 
clicked, which will stop the file processing.

if you want your GUI to respond to events while you are processing 
within a loop,

here is a trick to allow the application to work asynchronously... 
add :

wait 0


within your loop.  this way, the event mechanism has the chance to 
do its thing.  if the gui sets a global called Interrupt, you can 
then inspect that within your loop and exit.

ex:

forever [
	wait 0
	if interrupt [
		break
	]
]

obviously forever is used as a simple example, in your app your loop 
will be where you are cycling over each file name.

Maxim, perfect. Thanks. Thanks also to B.C. (My problem was getting 
the interface to allow a button to be pressed.)

I'm currently writing a Rogue like game with Rebol. I used a box 
to display the game map and set the focus on it so that it receives 
keyboard input but when I do that there is a weird white stripe being 
drawn on top of the box in the center. Any idea why that is and how 
I can make it go away? http://img.skitch.com/20100425-ju42itgetsasupi6yerc1ph4db.png

That's the caret. Use FOCUS/NO-SHOW, if you want keyboard access 
to a face, but don't want to display the caret.

Though I'm not sure if it can be done when there is other content 
in the face like that.

otherwise an alternative is to provide a sensor face, size 0x0, sitting 
in the corner. focus that and the caret won't appear. then control 
the main game area using the sensor face.

Will have to do that, no-show isn't working. Thanks :)

The caret is controlled by View on the C-layer, so there is not much 
else to do about it.