Re: [E-devel] the implementation of etox seems slow

2005-08-22 Thread The Rasterman
On Sat, 13 Aug 2005 11:33:08 -0400 Tianran Chen [EMAIL PROTECTED] babbled: the problem is - the evas api is DEFINED to accept utf8 as all strings. all strings are utf8 as far as it is concerned. it expects them in utf8 and will return them in utf8. so if you have anything that is not utf8

Re: [E-devel] the implementation of etox seems slow

2005-08-22 Thread The Rasterman
On Sat, 13 Aug 2005 05:34:24 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: On Sat, 13 Aug 2005 02:16:49 -0400 Jose writes: You could make this work by letting such 'layout engines' use smart objects and be given as external libs, ie. libs like edje. You'd create,

Re: [E-devel] the implementation of etox seems slow

2005-08-22 Thread The Rasterman
On Sat, 13 Aug 2005 02:16:49 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: You could make this work by letting such 'layout engines' use smart objects and be given as external libs, ie. libs like edje. You'd create, via the particular text format/layout lib, objects of whatever

Re: [E-devel] the implementation of etox seems slow

2005-08-13 Thread Jose O Gonzalez
On Sat, 13 Aug 2005 13:49:11 +0900 Carsten writes: On Sat, 13 Aug 2005 00:24:25 -0400 Tianran Chen [EMAIL PROTECTED] babbled: i did see the utf8 code. but utf8 is far from universal, now one of my handheld computer uses alot utf16 and GB, which evas_commont_utf8_* cannot handle.

Re: [E-devel] the implementation of etox seems slow

2005-08-13 Thread Jose O Gonzalez
On Sat, 13 Aug 2005 02:16:49 -0400 Jose writes: You could make this work by letting such 'layout engines' use smart objects and be given as external libs, ie. libs like edje. You'd create, via the particular text format/layout lib, objects of whatever format type you want

Re: [E-devel] the implementation of etox seems slow

2005-08-13 Thread Tianran Chen
the problem is - the evas api is DEFINED to accept utf8 as all strings. all strings are utf8 as far as it is concerned. it expects them in utf8 and will return them in utf8. so if you have anything that is not utf8 and you want to give it to evas - you must convert it to utf8 first, and

Re: [E-devel] the implementation of etox seems slow

2005-08-12 Thread Tianran Chen
* opaque string buffer. allow the use of other fast string libraries like vstr. can you explain in more detail? textblock is intended for: if i'm not mistaken, the string buffer is now string of [char] and is manipulated throught [str*] functions. i suggest use some opaque type (say call

Re: [E-devel] the implementation of etox seems slow

2005-08-12 Thread The Rasterman
On Fri, 12 Aug 2005 23:30:22 -0400 Tianran Chen [EMAIL PROTECTED] babbled: * opaque string buffer. allow the use of other fast string libraries like vstr. can you explain in more detail? textblock is intended for: if i'm not mistaken, the string buffer is now string of [char] and is

Re: [E-devel] the implementation of etox seems slow

2005-08-12 Thread The Rasterman
On Sat, 13 Aug 2005 00:24:25 -0400 Tianran Chen [EMAIL PROTECTED] babbled: i did see the utf8 code. but utf8 is far from universal, now one of my handheld computer uses alot utf16 and GB, which evas_commont_utf8_* cannot handle. unicode is not yet 100% functional for CJK yet. the problem is -

[E-devel] the implementation of etox seems slow

2005-08-10 Thread Tianran Chen
i am still new to e17, so please do not mind my ignorance. the current implementation of etox uses a evas object for each bit of text. this is fine for static text. but for large text that changes frequently (say for web browser, or word processor, even) this seems quite slow. inserting a single