Angus Leeming wrote:
> Hmmmmm. I've discovered that a single press of a cursor key leads
> to:
>
> expose 633x752+0+0
> paint 633x752+0+0
> work_area_handler, received X11 expose event 633x752+37+67
> paint 633x752+0+0
>
> XScreen::expose posts an XEvent that is received by the second call
> to XWorkArea::paint. It's able, therefore, to only draw the
> subrectangle it's requested to draw.
>
> I've tracked down the first call to paint which is from
> fl_unfreeze_form. I have not been able to ascertain what is calling
> fl_unfreeze_form. Any ideas on how I might? Put that another way.
> How do I tell gdb to stop execution in fl_unfreeze_form so that I
> can type 'bt'. Will 'bt' do what I want?
>
> Clearly, if we can track down this fl_unfreeze_form (and remove it),
> then the Xforms frontend will become *at least* twice as responsive
> as it already is...
Ok, I've got things down to:
expose 633x752+0+0
work_area_handler, received X11 expose event 633x752+37+67
paint 633x752+0+0
which is as it should be. It turned out that there were two culprits.
The first was in my new XForms layout engine code where calls to
XFormsToolbar::show, hide did not check whether the toolbar was
visible/invisible respectively before invoking the machinery to reset
the layout of the entire window. (These calls come, in turn, from
XFormsView::displayToolbar which is called *every* keypress...)
So, the first is fixed. And the second? This innocuous looking call
leads to fl_freeze_form/fl_unfreeze_form being called on every
keypress.
void XMiniBuffer::set_input(string const & str)
{
lyxerr << "Current string is \"" << getString(input_) << "\",
replaced by \"" << str << "\"" << std::endl;
// fl_set_input(input_, str.c_str());
}
Typical output is:
Current string is "", replaced by "Font: Default, Inset: 0x9169ad4,
Paragraph: 6, Id: 70, Position: 182, Row b:137 e:211"
As to *why* XForms redraws the contents of every single widget here,
well your guess is as good as mine.
I don't suppose that my 'solution' is acceptable though ;-)
Maybe we should do as John has done in the Qt frontend already and
have separate widgets to display messages and to input commands?
--
Angus
