World: r3wp

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

maybe with HW acceleration, it will not be that much? But we have 
yet to see Cyphre's integration of such a stuff ...

Accelleration doesn't affect this

Unless you would use 2D video overlays that would reduce the number 
of redraws, like on Syllable

Hm.. my mistake... probably commented the SHOW command when i was 
testing ... so I can confirm that for redraw on each mouse move I 
get same CPU usage.. pretty high. So the problem will be elsewhere.

Sorry for that.. I should take a break... here is my test file: https://github.com/Oldes/R3A110/blob/master/tests/text-test4.r3

Oldes..don't search for any problem in this. When call the show on 
each mouse move I'm able to geterate more than 90 SHOW events per 
second without any 'wait' so it is understandable that such heavy 
forced rate on CPU calculated code steals lot of CPU time.

Ihe 'show on each mouse move' was in this test script just for easier 
bugfixing during my test sessions.

(I wouldn't advise to use such code in real apps)

Also I guess the performance difference between the ANSI/UTF16 on-the-fly 
conversion will be minimal unless you use megabytes of text.

Cyphre - but we want to create MS Word clone, so megabytes of text 
are expectable :-)

I'm looking forward to see a solution how you will redraw the text 
while selecting text. i guess we will need some sort of event filtering.

this in not rockest science to make 'redraw limiter' ...I guess I 
don't need to create an example for you

in case of 'text selection' you can call SHOW only when the selection 
really changes..this is not for every mouse event

Pekr, I hope you are just joking with your speculation that MS WORD 
is using always one big chunk of the whole text and redraws the whole 
window for every  text processing event ;)

jo, je to detail...  jak se spravne pouziva ten caret-to-offset, 
aby to nehodilo error, kdyz kliknes mimo text?

ech :/

Oldes, of course Rebol comunity will invite any good optimization 
of the hostkit code that will lead at least for a few percent of 
speedup. You can be useful here.

Cyphre - what was the result of your acceleration experiment (not 
talking JITTer here)? I do remember it provided some further speed-up 
to some folks here (not to me on intel chipset). Will it  be added 
to hostkit by default, if it works under all Windows versions?

There are no plans for the accerated graphics yet. It's early concept 
but it is highly portable and will work on all platforms that has 
OpenGL support.

nice ... even some xy percent speed-up is worth it :-) What I am 
interested in is the smooth, not CPU hungry scrolling, not sure if 
OGL can help here though :-)