Re: [gtk-list] Re: Text-widget

[Derek Simkowiak <dereks kd-dev com>]

> The mechanism in GTK+ for this is GtkBinding. The GtkEditable widgets
> were never converted over, but it was designed with this in mind.
> The biggest users right now are the GtkCList and GtkMenu code.

	I'll add this to my todo list for the new GtkText.  Thanks.

>  The gapped text buffer
>  The property list
>  The line start cache
> 
> This wouldn't necessarily be bad if they were separated out
> into conceptually separate objects with clean interfaces. 

	I've seen exactly what you are talking about.  I plan on getting
rid of (or changing the purpose/design of) "line start cache" since,
according to the document Josh wrote up, it gets "corrected" with every
insertion.  From what I understand, this is one of the speed bottlenecks.

> GtkText, please go and look at correct_cache_insert() for

	Heh...

> Basically, if a design is so complex that the assertions one adds
> are incorrect, then I cannot in any way consider it sound.

	I think using the gapped text buffer is the best way to go about
it (it's a popular, well-understood mechanism that seems to get the job
done) and the property list also seems pretty sound (I haven't seen any
reason to abandon the structure--only its API).  See gtk-devel-list for
some of the ideas I'm playing around with for the drawing of the text...

[re: slowness]
> Hmm, actually, no I don't. I tuned GtkText to perform decently
> on a 7000 line text file on a P133-class machine, and I really
> can't detect any noticeable at all slowness on such files on
> the machines I have available to me.

	I can type faster than the widget draws on a Pentium-class
(don't know if it's a PII or what) 450Mhz machine running Gtk+ 1.2.3,
when I maximize a GtkText to full-screen.  And that's without a pixmap
background.


> > 	I'm working on the problem.  I'm currently desiging a new
> > rendering pipeline
> 
> pipeline? I don't see how this term makes any sense here.

	Sorry, I'm thinking in terms of 3D graphics programming.  I see
the gapped text buffer as my data set (a binary space partitioning tree in
the OpenGL world), and I clip that to the viewable (or soon-to-be-viewed)
text (the node of the BSP tree I'm in, if this were 3D :).  In practice,
this "clipping" is really just seeing what text and associated property
list items are visible).  Then I "render" that to a pixmap, clip it to the
viewable window.

	Okay, so upon further inspection the analogy stinks.  Sorry.

> Horizontal scrolling would be easy enough to implement in the 
> current framework for rendering. Especially as it really
> wouldn't hurt to just render the whole line anyways and let
> it get clipped. 

	The problem is that all of the calculations in draw_line expect
the left-most pixel to be "zero" (the first pixel on any drawn line), and
it gets drawn directly to text->text_area, the GdkWindow.  This messes
with the cursor drawing/undrawing calculations, and everything else.

	I'd need to add some variables to the GtkText widget (such as the
maximum pixel width in the displayed text) and some of the sub-structs
(line the lineparams, what the left-most pixel is) and as you said the
code is intermingled throughout.  I think it would be easier to clean up
the ProperyList and gapped text segment APIs and then have a new rendering
pipeline (or whatever you call it :).


--Derek