Hello,
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
As a test, I put a little bit of (incomplete) Nepalese support. For those who would like to try right now, do it a bit hard way on Linux:
- Get the latest VMMaker image, update RomePlugin to the latest version with the Monticello browser. Generate source code to compile the VM. - Update the etoys-3.0 image to the latest. - Switch the language to Nepali from the flag in the menu bar. - Change the keyboard layout to devanagaari by something like: setxkbmap -layout in -variant deva
and type Devanagaari into Etoys.
Clipboard isn't quite right (even though it may seem to be working), but let me know if the keyboard works as expected.
Sometime this week, we'll release the VM so that you don't have to build the VM by yourself.
Thank you!
-- Yoshiki
Am 25.06.2008 um 07:48 schrieb Yoshiki Ohshima:
Hello,
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
As a test, I put a little bit of (incomplete) Nepalese support. For those who would like to try right now, do it a bit hard way on Linux:
- Get the latest VMMaker image, update RomePlugin to the latest version with the Monticello browser. Generate source code to
compile the VM.
You can also simply check out the latest svn from the olpc branch and recompile.
Or, if you use sugar-jhbuild, do "sugar-jhbuild buildone squeak"
Or, use my precompiled RomePlugin. To install on the XO:
cd /usr/lib/squeak/3.10-3 wget http://dev.laptop.org/~bert/RomePlugin.gz gunzip RomePlugin.gz
- Update the etoys-3.0 image to the latest.
- Switch the language to Nepali from the flag in the menu bar.
- Change the keyboard layout to devanagaari by something like: setxkbmap -layout in -variant deva
and type Devanagaari into Etoys.
Clipboard isn't quite right (even though it may seem to be working), but let me know if the keyboard works as expected.
Sometime this week, we'll release the VM so that you don't have to build the VM by yourself.
Please test! There definitely are still bugs. I already reported some:
https://dev.laptop.org/ticket/7320 https://dev.laptop.org/ticket/7344 https://dev.laptop.org/ticket/7345 https://dev.laptop.org/ticket/7347
(7345 appears to be even worse without Pango, so that one could be tested on non-Linux machines - hint hint)
- Bert -
Am 25.06.2008 um 07:48 schrieb Yoshiki Ohshima:
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
One reason for the performance degradation is that the Pango rendering methods flush the whole screen. That is, for every little string there is a BitBlt of 1200x900 pixels converting from 32 to 15 bpp. To only flush the affected area, you need to give a rectangle parameter to #finish:.
Also, for each string/paragraph it actually allocates, draws into, and discards a 1200x900x32 Cairo bitmap surface. I did not measure how expensive that is, but it could be avoided by reusing one Cairo surface for all rendering (the affected region will have to be cleared in between of course).
- Bert -
At Wed, 25 Jun 2008 17:43:40 +0200, Bert Freudenberg wrote:
Am 25.06.2008 um 07:48 schrieb Yoshiki Ohshima:
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
One reason for the performance degradation is that the Pango rendering methods flush the whole screen. That is, for every little string there is a BitBlt of 1200x900 pixels converting from 32 to 15 bpp. To only flush the affected area, you need to give a rectangle parameter to #finish:.
Oops. I thought I did. Maybe there was a reason somehow it didn't work (I can't remember).
Also, for each string/paragraph it actually allocates, draws into, and discards a 1200x900x32 Cairo bitmap surface. I did not measure how expensive that is, but it could be avoided by reusing one Cairo surface for all rendering (the affected region will have to be cleared in between of course).
Yes, RomePluginCanvas class>drawingCanvasFor: was a little attempt to reuse the surface but the commented part didn't work.
Patches are welcome!
-- Yoshiki
On Wed, Jun 25, 2008 at 11:33 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
Hello,
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
<snip>
and type Devanagaari into Etoys.
Sorry for the delay, but SWEEEET!!!!!!
Just tested this, and it works without a hitch (not having tested this enough to know the problems we'll run into in actual projects of course) ! Very cool. This is going to save us a lot of time and space, and opens up the way for easy internationalization. Thanks a lot for making this work!
/Ties
2008/7/18 Ties Stuij cjstuij@gmail.com:
On Wed, Jun 25, 2008 at 11:33 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
Hello,
We are making another progress on the text rendering support with Pango. This time, I'm even comfortable to mention it publicly!
<snip>
and type Devanagaari into Etoys.
Sorry for the delay, but SWEEEET!!!!!!
Just tested this, and it works without a hitch (not having tested this enough to know the problems we'll run into in actual projects of course) ! Very cool. This is going to save us a lot of time and space, and opens up the way for easy internationalization. Thanks a lot for making this work!
I'm also interested by this work, because i will move in october in Vietnam (Hanoi) for two years and i would like to have a vietnamese EToys version.
At Fri, 18 Jul 2008 14:35:17 +0200, Serge Stinckwich wrote:
I'm also interested by this work, because i will move in october in Vietnam (Hanoi) for two years and i would like to have a vietnamese EToys version.
That is good. If you can get some people, they can start the translation effort now.
-- Yoshiki
At Fri, 18 Jul 2008 15:16:11 +0545, Ties Stuij wrote:
and type Devanagaari into Etoys.
Sorry for the delay, but SWEEEET!!!!!!
But it is a nice timing for me to get the feedback somehow. (I am going to show it at the internal meeting today).
Just tested this, and it works without a hitch (not having tested this enough to know the problems we'll run into in actual projects of course) ! Very cool. This is going to save us a lot of time and space, and opens up the way for easy internationalization. Thanks a lot for making this work!
But there are still more to go, as you know. The performance part has a big room for improvement. The clipboard code is not complete (it would look to be working, though). And let us know any problem you find. Thank you!
-- Yoshiki
At Fri, 18 Jul 2008 08:35:59 -0700, Yoshiki Ohshima wrote:
But there are still more to go, as you know. The performance part has a big room for improvement. The clipboard code is not complete (it would look to be working, though). And let us know any problem you find. Thank you!
Bert fixed the biggest performance issue last night and published a change set (2059pangoSpeed-bfyo.cs). When do the experiment, please try in the fully updated image. (Yes, now, the rendering with Pango is generally faster than the native rendering in Squeak.)
-- Yoshiki
Am 19.07.2008 um 08:29 schrieb Yoshiki Ohshima yoshiki@vpri.org:
At Fri, 18 Jul 2008 08:35:59 -0700, Yoshiki Ohshima wrote:
But there are still more to go, as you know. The performance part has a big room for improvement. The clipboard code is not complete (it would look to be working, though). And let us know any problem you find. Thank you!
Bert fixed the biggest performance issue last night and published a change set (2059pangoSpeed-bfyo.cs). When do the experiment, please try in the fully updated image. (Yes, now, the rendering with Pango is generally faster than the native rendering in Squeak.)
-- Yoshiki
It just occurred to me that we have not tested if this works correctly after saving and restarting the image ... Rome should take care of this, but we should test nonetheless.
- Bert -
It just occurred to me that we have not tested if this works correctly after saving and restarting the image ... Rome should take care of this, but we should test nonetheless.
Yes, RomePluginCanvas class>>shutDown nils out the variables and shutdown instances, so it is fine.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Serge Stinckwich -
Ties Stuij -
Yoshiki Ohshima