World: r3wp

It could be fixed if we could change the ansi string to unicode and 
store it for later use.. I'm just a C newbie, but I don't think it's 
how it works now.

Does AGG have separate 8bit and 16bit rendering APIs or is it always 
one or the other?

I think it has only 16bit.

But I'm not so far to be sure.

If it is UCS-2 or UTF-16, then all that would need to be done is 
to convert UCS-1 model R3 strings to UCS-2 mode somewhere before 
rendering. (He says glibly, having not analyzed the AGG sources or 
APIs.)

I'm still guessing this only applies to AGG on Windows, using UTF-16. 
On other platforms, AGG uses FreeType, and I guess that would accept 
UTF-8

Submited it to CC http://curecode.org/rebol3/ticket.rsp?id=1814so 
Carl could answer eventualy.

I think the file you're looking at is not really part of AGG, but 
written by Cyphre as a bridge between AGG and Windows

I know. But it does not solve the issue.

The issue is we have to wait for the Amiga patches, which should 
constitute the bridge to FreeType systems

Also I'm not sure REBOL is using UTF-8 internally, I think it has 
only ANSI or UCS2

No, as Brian says, it's using fixed width vectors internally. You 
get UTF-8 only from conversions

which means that FreeType will be affected as well.

Yes, we knew since the Unicode epic that we would need conversions

But for each redraw? The conversion is fine, if is only one.

That can be cached

The text conversion is actually a minor matter. Code points also 
need to be converted to pixel glyphs, and heavy caching is always 
used there to arrive at usable performance

Btw... it's the reason why I'm hacking the code... I would like to 
enable bitmap fonts. AGG supports that, but I don't think that Cyphre 
has enough time to work on it alone:)

Unfortunately instead of experimenting with agg itself, I must solve 
issues which are already solved but not public yet.. but at least 
I'm learning.

Rebol strings are stored either as ANSI (one byte) or wide char (double 
byte). Of course the rich-text module is currently doing the conversion 
for every rendered ANSI string in realtime. Any sophisticated rich-text 
caching is not yet implemented. (note: this has nothing to do with 
font glyph cache which works well) But even though the cache of large 
text block is missing the performance is still very usable for normal 
GUI cases so the priority to spend time on the line-cache is not 
too high at the moment.

I understand what Oldes wants. He want to be able to change already 
allocated Rebol string! from ANSI to WIDE-CHAR 'mode' so next time 
the conversion is not needed. Tha could be useful but has to be decided/implemented 
by Carl in the hostkit api.

Also it would be interesting to see how big is the difference between 
on-the-fly conversion performance to see if it really makes sense 
to permanently take two times more memory for such Rebol string or 
just do the temporary on-the fly conversion as it  works now.

I can imagine, if there is a lot of the text, that scrolling such 
a text, might be influenced in performance, or not?

It's possible to do such a test... just to compare the performance 
with ansi strings only and with strings which contains non ansi chars 
as well (so are stored as wide char internally). I can try it once 
I will have some time again.

that would be nice ...

But I would rather wait for the RMA's host-kit release before the 
test.

For those who are impatient I put the RMA Host-Kit on this URL: http://www.rm-asset.com/code/downloads/files/rma-host-kit.zip

It's not yet on the official RMA download page but Robert will be 
updating the page content soon.

Published: http://www.rm-asset.com/code/downloads/

That "soon" was 3s

LOL thats really quick :)

R3 final will be out soon.

.... nothing happened :-(

maybe it works only with my messages...should I try again? ;)

that's cheating. you just finalized R3 while we were talking. :-)

R3 final? I suppose this means R3 is now beta instead of alpha. That 
is good news because it means I may be able to get an updated libr3.so 
for the Amiga soon. I'm waiting on that library so I can continue 
work on the host kit and submit my changes.

it was a joke on using the word "soon" for releasing some source 
code, which then occurred a few seconds later :-)

so... R3 final is not ready yet.

Is there any reason why the init code is defined like:

https://github.com/Oldes/R3A110/blob/02a64ba7e8e23d623c0f75244e8989f05898494e/src/include/host-ext-draw.h#L95
instead something readable like:

https://github.com/Oldes/R3A110/blob/63c34452dfed0929d75dca1d7f2fdc454ae7d37e/extension-demo/src/demo-ext.c#L8

grrr... (the middle line is "instead something readable")

the init-code is generated by rebol script so there is no need to 
write it that way 'by hand'

in other words..you are looking at  generated file..not the original 
source

I know... but it can be generated in a redable form, cannot be?

Maybe there is a reason, because in the script which is building 
the files is a comment: Conversion to C strings, depending on compiler

Probably, as Carl wrote the script. Anyway, I don't see a reason 
why I should read the auto-generated source in any of the mentioned 
format when I can read it as normal rebol script in the original.

I modified text-test3.r3 script from the host-kit to use normal sized 
font (12) not anti-aliased and used a little bit longer text content 
(but not extremely much. just two lines with length cca 1400 chars)... 
the result is:

Good news: I do not notice any difference between ansi/unicode content.

Bad news: in both cases R3 uses almost 23% of my CPU time when I 
just move mouse over the text, which is pretty much:/

good news.. there is [show win] on move event what explains that.

But it's still an issue... as it uses same (or even more) CPU as 
when I'm selecting colorized code is Crimson's full screen window.

I take it back... it's the conversion!... I was not using utf8 so 
both my tests were pure asci = now I'm sure that  ASCI versus UNICODE 
string content makes 23%CPU versus 1%CPU

I will polish the test file and attach it to the bug report.

that seems significant ... will dry battery faster ...

That's much more than I expected