World: r3wp

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 :-)

Also there is significant amount of testing/work that needs to be 
done and my time is limited. But I personally plan to get back to 
it during this year but have no high priority for that unless R3 
will be ported to some other interesting devices (game consoles, 
smartphones, tablets etc.).

CPU are dead in they actual from ... the futur is APU and it would 
be crazy not to adapt VID to feet that new specication especially 
for small devices (smart phones, tablets, notebooks etc ..).being 
AMD being APPLE being Intel or ARM they all look to reduce latency 
in their device by integrating high level GPU into their CPUs.

Integrating gfx into CPU is just that - integration of gfx into CPU 
- it has nothing in common with the proach to create SW, no? :-)

hum pekr so why IE and other MS software like powerpoint now integrate 
a Hardware acceleration capabilities properly brough by sandybridge 
and fusion APU.

Powerpoint integrate acceleration for ages ....

not that kind

http://www.youtube.com/watch?v=qsfwx5Tv4fo

in this video Pekr as a matter of  fact powerpoint 2010 has hardware 
acceleration and not the 2007 ...

whatever - but it is not related to APU, as you tried to suggest. 
It is just that now most of PC configs out-there, even with Intel 
gfx chipsets, will be hw accelerated ... which is a good thing ... 
except the REBOL not supporting hw acceleration :-)

Hardware acceleration of graphics is a good idea. The APU thing cuts 
down on the posibilities of that because the graphics processors 
tend to be on the scale of integrated graphics, due to the size, 
but that won't be the case for long, and graphics acceleration is 
still a good idea.

BrianH thank you :) ... As a side note GDI is deprecated and abandonned 
massively on hardware level... but Gfx libs like Cairo support directX 
rendering hardware accelaration or OpenGL depending the plateform 
... I'm not quite the super exper on the topic. But i know that's 
a tendency to move back graphical content to the GPU  and not only 
when it comes to 3D rendering ...

(This should be in the !REBOL3 Graphics group, where it will b e 
useful)

If you give an index to RL_GET_STRING on a series of single bytes, 
it will return an address computed as if the items are double bytes

I'd guess RL_GET_STRING is currently hardcoded to always count in 
double bytes

RL_GET_STRING returns number > 0 if the source is unicode and < 0 
if ascii

at least on windows

Yes, that's not the issue. I'm inversing the length because the series 
is always a BINARY

The issue is that it computes it as items of double bytes instead 
of one byte

The address, that is. The length is correct

So that's why I didn't notice the corruption, because all the length 
calculations are correct, but the wrong data is passed