[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSTextField
From: |
Stefan Böhringer |
Subject: |
Re: NSTextField |
Date: |
28 Jun 2002 14:02:17 +0200 |
To compare implementations you should better look at MacOSX rather than
Openstep since Openstep makes use of a special display postscript
operator called highlight (IIRC). This is quite of a hack since it
replaces pixels in the framebuffer of one color with another one (say
replace white pixels with gray ones). This is a implementation running
quickly but not well portable.
Why is there both, a selectText: and a mouseDown: method sent? From a
glance I cannot reproduce your described behaviour (say in GWorkspace).
Best wishes,
Stefan
On Fri, 2002-06-28 at 13:44, David Ayers wrote:
> Hi Stefan,
>
> --------------------------------------------------------------------------
> 2002 Jun 28 - 13:25
> Stefan Böhringer <stefan.boehringer+usenet@uni-bochum.de>
> --------------------------------------------------------------------------
> >I see your problem now. The question is what triggers the
> >setNeedsDisplay:YES call which in turn causes the flickering. Is it the
> >drawing of the selection?
>
> Yes, this triggers the setNeedsDisplay, and it's OK that it does so.
>
> > Perhaps a delayedPerform: could help to
> >postpone the redrawing. Then again I do not know about the point in time
> >when delayedPerform: methods are executed.
> >Another question is what is flickering after all. If it is the whole
> >window this indicates that redrawing is too extensive and should perhaps
> >be optimized in the first place.
>
> It's not real flickering. If you click inside a TextField (with contents) it
> will select the entire content shortly and then reinsert the insertion point
> at the location of the click. (or show the actual selection if you
> dragged-clicked)
>
> I still couldn't test it on openstep, yet I found some documatation that
> makes me beleive that the flushWindow approach is the correct way to do this.
> As I said, only NSBackingStorNonretained is still causing this effect with
> the enable/disableflushWindow approach but the online Docs from Apple
>
> http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/WinPanel/index.html
>
> also mention:
> "Both retained and nonretained windows are also subject to a flashing effect
> as individual drawing operations are performed, but their results do get to
> the screen more quickly than those of buffered windows."
>
> So my guess it, something similar will happen.
>
> Dave
>
> PS: Thanks again Richard for the tip on exception handler to ensure flushing
> will be reenabled. And I also think the _handleWindowNeedsDisplay: should
> reschedule itself in case isFlushWindowDisabled returns YES and just return.
> I'll try to get the modifications together soon.