Re: GTK+ performance problem



By redundant marks, I meant multiple marks at the same place, with the same name (or no name), and the same gravity.

How about changing the create mark function to return the existing mark if the created mark would be the same?

Here is the documentation I was using:
� (http://developer.gnome.org/doc/API/2.0/gtk/GtkTextBuffer.html#gtk-text-buffer-create-mark)

gtk_text_buffer_create_mark ()

GtkTextMark* gtk_text_buffer_create_mark� (GtkTextBuffer *buffer,
�������������������������������������������� const gchar *mark_name,
�������������������������������������������� const GtkTextIter *where,
�������������������������������������������� gboolean left_gravity);

Creates a mark at position where. If mark_name is NULL, the mark is anonymous; otherwise, the mark can be retrieved by name using gtk_text_buffer_get_mark(). If a mark has left gravity, and text is inserted at the mark's current location, the mark will be moved to the left of the newly-inserted text. If the mark has right gravity (left_gravity = FALSE), the mark will end up on the right of newly-inserted text. The standard left-to-right cursor is a mark with right gravity (when you type, the cursor stays on the right side of the text you're typing).

The caller of this function does not own a reference to the returned GtkTextMark, so you can ignore the return value if you like. Marks are owned by the buffer and go away when the buffer does.

Emits the "mark_set" signal as notification of the mark's initial placement.




Owen Taylor wrote:
On Thu, 2006-09-14 at 16:44 +0200, mikecorn wrote:
  
Owen,

Thanks for your response. In answer to your question, I did what I
thought the documentation said to do in order to scroll the window so
that newly appended text came into view. You are right that I was
creating thousands of marks, something I realize only now. After
playing around with a small benchmark and reading the documentation
more carefully, I realized the mark would move to the end of the
inserted text and did not need to be created each time.
    

Which documentation? that documentation could be fixed.

  
Perhaps the create mark function could be enhanced to detect and
reject (or report) redundant marks? It seems that I had created
thousands of unnamed redundant marks at the end of the text buffer. 
    

I'm not sure what would count as a a redundant mark.

					- Owen

(The GtkTextView actually has an internal system where it will create
a temporary mark at an iter, scroll to it, and when the scrolling is
done, delete the iter. It would be really handy if there was some
scroll-to-iter variant that behaved in that manner.)

  


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]