I think this discussion is probably boring the majority of the people on the
Unicode list to tears, so I will keep this as brief as I can. I must also
say that it is getting repetitive and generating no new information.
ATSUI is focused primarily on making it easy to do high-quality, compliant
rendering of Unicode text with good performance. With some notable rough
spots, it meets this goal. Font menu construction and font substitution are
two of the known problem areas. It is also possible to get poor performance
if ATSUI is used in a naïve way; the documentation needs to point out these
pitfalls.
Easy adoption by people with their own text editing/rendering engines was
not a goal for the first releases. First we wanted a solution for the
majority of applications, so they could draw Unicode correctly in all the
countries in which Apple ships systems. A QuickDraw-like API would have
dumped the problems of correct Unicode rendering in the developer's lap, and
experience shows that developers generally don't have the expertise to do
this correctly.
We plan to add features to better support applications with their own layout
engines in future releases. This is a high priority. We did not want to wait
to release *any* Unicode rendering solution until we had all possible bases
covered. Software needs to be used in order to shake out the rough spots.
As for converting SimpleText, using ATSUI is not a reasonable comparison, as
SimpleText uses TextEdit, not its own layout engine. A more fair comparison
is with MLTE. Converting an application that uses TextEdit to use MLTE takes
a very short period of time. I believe Marco said he did it in a day.
I am sorry you cannot get ATSUI to work for you the way you want. That
doesn't change the fact that it is quite functional and performs well for a
number of applications. I regularly use an MLTE-based text editor and I have
no problems with the performance.
If you want to carry on this conversation I suggest you take it to private
e-mail. I don't think it's productive to keep bringing up the same concerns
over and over again in this forum.
Deborah Goldsmith
Manager, International Toolbox Group
Apple Computer, Inc.
goldsmith@apple.com
on 1/31/2000 12:38 PM, Yung-Fong Tang <ftang@netscape.com> wrote:
>
>
> Deborah Goldsmith wrote:
>
>> on 1/29/2000 3:00 PM, Franko <franko@omnibus.se> wrote:
>>
>>> Deborah Goldsmith skribis:
>>>
>>>> make a quick MLTE demo app available. Thank you, Marco!
>>>
>>> MLTE Demo takes an eternity to start. Is that because it is just a demo,
>>> or does that depend on initialisation of ATSUI? Jean Michel at CMT
>>> Development comments that "It seems that initialising ATSUI is still
>>> taking very long and would represent a serious penalty for roman-language
>>> PowerMail users if we had depended on ATSUI".
>>
>> On my 300 MHz G3, I timed it as between 12 and 16 seconds. I guess it
>> depends on what your definition of "eternity" is.
>
> That mean 36-48 seconds in a 100 M Hz machine, right ?
>
>>
>>
>> Undoubtedly most of this time is building the font menu, especially if you
>> have a lot of fonts (I have a hundred or so, for the tests above). This is
>> something we know needs performance improvement. Initializing ATSUI itself
>> takes just a couple of seconds.
>>
>> A workaround for now is to cache the font menu and rebuild it if the Fonts
>> folder changes.
>
> How can you know the font folder is changed or not ? DO you have a
> notificatoin
> scheme ?
>
>> AppleWorks uses this technique. The Kotoeri in OS 8.6-J had
>> this same problem; it was fixed for Kotoeri in OS 9.0-J. OS 9.0 Language
>> Kits has the 8.6 version of Kotoeri, so you'll still see this problem when
>> Kotoeri is initialized for the very first time.
>>
>> Perhaps some of these developers would like to communicate directly with
>> Apple, in particular with me, if they have suggestions for where ATSUI needs
>> performance work? This is something we are in the process of doing right
>> now. If no one gives us the information on what they consider too slow, it's
>> not going to improve. I guess I don't understand why these comments aren't
>
>> being sent to us.
>
> I have send comment to Apple directly about the quality and performance ATAUI
> for over one year. I have not get positive feedback from Apple so far.
>
> Write some code to draw some text with 20 different font 10000 times. Do the
> same thing with ATSUI and QuickDraw. What is the ratio ?
>
> I think the performance problem of ATSUI fall into the following category-
> 1. Performance caused by different interface model-
>
> ATSUI interface does not design to work will with old application. Basically,
> there are no easy way to simply modify the rendering part of existing Mac
> QuickDraw application or application code from other platform to support
> ATSUI.
> Which mean there are no easy way to migrate old application code to support
> ATSUI. ATSUI require you to build layout object, which is a higher level
> object
> than the QuickDraw primitive operation. Because of this kind of NEW model, it
> is
> very simple for any application to program in a way which use ATSUI in an
> inefficient way. It assume everybody are willing to rearchitect their
> application for ATSUI. It encourage NEW program instead of migration exisiting
> code. It pay no attention about co-exist with old QuickDraw code. (Although,
> it
> is possible to design it and co-exist with new QuickDraw code).
>
> From my point of view. This is the same as QuickDraw GX. Apple folks
> definitely
> did not learn from the falure of QuickDraw GX and redo the same mistake on
> ATSUI
> again- except this time it use the same memory manager.
>
> Deborah- Take the SampelText source code and try to migrate it to use ATSUI by
> yourself. Feel the pain. Make sure you allow your new SimpleText can still use
> QuickDraw if ATSUI is not present.
>
> 2. Performance in the average usage-
> I think this is the most important part of performance. I have no big complain
> about it. As you point out, font menu probably need some work. We have not use
> the ATSUI font menu yet. So I cannot give you comment in here.
>
> 3. Performance in the worst case-
>
> If you turn on the font fallback and let the ATSUI try every font, the
> performance of hiting character which do not have any glyph in any font shold
> be
> within reasonable time. It could be slow, but it should not be slow as
> freezing
> the computer.
>
> I once try to use ATSUI to render character for Mozilla. 256 code point at a
> time and repeate 3 times in my test page. When we hit the testing page which
> there are no font can render, it freeze my computer for > 2 minutes.
>
> I am forced to not use ATSUI now unless I know the character I need to render
> is
> gurantee can be displayed with a font. I have no way to do this now in ATSUI
> and
> are forced to use one pre-build hardcode table.
>
> This area probably is not that important for other applicaiton. But for an
> internet browser, we have to ensure web site server cannot attack the client
> user by sending this kind of page which will virtually freeze the computer.
>
>>
>>
>> Deborah Goldsmith
>> Manager, International Toolbox Group
>> Apple Computer, Inc.
>> goldsmith@apple.com
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT