World: r3wp

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

Pushed a few of my straight-forward A110 patches, mostly about mildly 
re-structuring the build. to https://github.com/earl/R3A110.

Here's a chronological list of commit summaries:

8ed0b68 Rename about.txt to README
45bf64d Temporarily remove unmaintained build projects
f7237b4 Move libs to platform-specific subdirectories
f8eb7e6 Move makefile to platform-specific subdirectory
5072f47 Remove reb-to.h and pass TO_<target> as compiler flag
2401c40 Minor makefile cleanups
333edad Linux: fix bug#1658: link binaries against libdl
3f1fd7d Linux: improve linkage to libr3
635f228 Win32: add makefile

4f57323 Win32: raise the stack size limit in the resulting binaries
048678b OSX: add makefile for osx-intel (untested)

For more details, see the full commit messages, or just ask me :)

Hasn't Carl supposed to have build A111 ?

Many of those may already be superfluous with the upcoming A111, 
but we'll see :) I intend to forward port whatever makes sense.

All of those changes where discussed (mostly in the "R3 Source Control" 
group) back in November before Carl went incommunicado in this AltME 
world.

Carl's disappearance also made me forget about those changes. But 
as he writes in his most recent R3 blog post "If I can find any other 
changes this weekend, I will merge them.", maybe they still are of 
any use.

Otherwise we'll see after the A111 release :)

a blog???

http://www.rebol.net/r3blogs/0351.html

he's alive!

Has anyone tried compiling the hostkit for MinGW with the Cygwin 
compiler set? I'm trying to minimize the number of GCC installations 
on my Windows machine, and the Android NDK requires Cygwin to do 
its build process.

should be possible (and rather unproblematic) but give you something 
very different

mingw-compiled .exe's are native win32 exes, cygwin-compiled stuff 
depends on the cygwin runtime

so cygwin gcc really != mingw gcc, just as linux-x86 gcc != linux-arm 
gcc

(at least last time i looked at cygwin, which was years ago. but 
i doubt things have changed much)

Cygwin can compile MinGW exes, Linux exes, Android ARM exes, etc. 
I am more concerned with the makefiles and settings involved.