RE: Q on performance with 10000 faces

["Drew Adams" <drew.adams@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]

    > Does this mean that Emacs cannot reasonably be expected to
    > display 10000 face text-properties?

    AFAIK, yes.  Doing what you did (a) disables all possible display
    optimizations that the redisplay engine has up its sleeve to speed up
    the common cases, and (b) forces Emacs to traverse the 10000 text
    properties for each character it is about to display.

What is it that you think I did that causes that? Perhaps I could do things
differently. Do you mean just the fact of using 10000 different face text
properties or something else also?

    > If so, any advice on workarounds or other approaches?

    I don't know of any, except ``don't do that'', but perhaps Kim or
    Stefan will.

Don't do what? Use that many faces or something else also?

    > Is the slowdown perhaps because of some kind of automatic updating or
    > refreshing, which I could turn off somehow (I hope)?

    It's because even cursor motion, that usually takes a fast shortcut
    through the redisplay code, requires to search all the text properties
    in your situation.

I'm a little surprised that a frame that is not selected and has no current
activity (no cursor motion etc.), would continue to slow Emacs down just by
being displayed on the computer screen (and listening for input). I can see
why activity within that frame (or moving the frame, or moving another frame
across it, etc.) might cause Emacs to slow down due to redisplay, but the
same slowness continues even when that frame is ignored (just sits there,
selected or unselected).

I'd appreciate any advice on achieving the same end, either in some other
way or by somehow tweaking this approach.

I guess one alternative would be to insert an image of a complete palette
(like the image attached) and implement something similar to an HTML image
map (unless that functionality already exists in Emacs), to pick up the
position of a mouse click. That is, monitor mouse-click positions, and work
backward to determine the picked color. But that would require associating
the original color info (e.g. #RRRRGGGGBBBB with image positions. The
advantage of the approach I chose is that each character's text property has
the color info within it. Of course, if the approach isn't realistic due to
display performance, it's back to the drawing board.

I'm not familiar with the Emacs treatment of images. Looking in the Elisp
manual for info on them, I didn't see anything similar to HTML image maps.
Is there such a functionality already?

Attached is a screen capture of my hue x saturation palette (the 100 char x
100 char frame that slows Emacs down), to give you an idea of the kind of
thing I'd like to do. (The frame could be made square if I could figure out
a way to get rid of inter-line spacing.)

Thanks for the info.

[-- Attachment #2: hue-x-saturation-palette.jpg --]
[-- Type: image/jpeg, Size: 31291 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel