Re: white screen windows at first
Re: white screen windows at first
- Subject: Re: white screen windows at first
- From: Jesper Storm Bache <email@hidden>
- Date: Tue, 27 Apr 2010 20:32:40 -0700
- Acceptlanguage: en-US
- Thread-topic: white screen windows at first
FYI: the screen disabling stuff is unlikely to be the issue here (as I mentioned in a sub-sequent email). One reason is that it only is used for windows that are already visible.
Both Cocoa and Carbon will send you a draw request before your window is visible (to avoid a white flash), so that would be the current best bet.
Good luck,
Jesper
On Apr 27, 2010, at 6:12 PM, Bill Appleton wrote:
hi all,
this is helping
one thing you app migrators out there need to remember is that cocoa draws the window before it is visible
so there is a timing issue
i will check these issues tomorrow
thanks,
bill
On Tue, Apr 27, 2010 at 4:24 PM, Jesper Storm Bache <email@hidden<mailto:email@hidden>> wrote:
I though I saw that you said that you create windows before you call NSApplicationMain.
If this is so, why are you getting draw operations?
The typical use case is that you create windows after the NSApplication has entered its event loop. This is done as windows are flushed when NSApplication (internally) calls nextEventMatchingMask.
If you create a bunch of windows outside the event loop & if it takes longer than 1 second to initialize then a potential window server "update disablement" times out and you may see flashing at the time of the first event. "disablement" is initiated when someone calls NSDisableScreenUpdates or disableScreenUpdatesUntilFlush - when this happens updates must be re-enabled within a second to avoid flicker. AppKit internally calls these methods in a number of cases (such as when it changes the frame of a window).
You can see if the window server times out by looking at the window server log in the console.
Jesper
On Apr 27, 2010, at 4:01 PM, Bill Appleton wrote:
i have tried that way
CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort];
and this way
NSWindow *mywindow;
CGContextRef context = [[mywindow graphicsContext] graphicsPort];
they return the same pointer
then i have also looked at the CGContextRef i get
-- the transformation matrix is identity
-- the clip bounds box looks fine
but you can NOT draw into that cg context!
later, if you resize & muck around, you can...
thx
bill
On Tue, Apr 27, 2010 at 3:43 PM, Jesper Storm Bache <email@hidden<mailto:email@hidden>> wrote:
How do you get your coregraphics context?
You should do:
CGContextRef context = reinterpret_cast<CGContextRef>([[NSGraphicsContext currentContext] graphicsPort]);
Jesper Storm Bache
On Apr 27, 2010, at 3:36 PM, Bill Appleton wrote:
> this problem must be because i am using core graphics
>
> i painted a big red rectangle in drawRect and then went on and called my
> core graphics code
>
> the big red rectangle comes up every time
>
> but only after resizing do i see the stuff i draw with core graphics
>
> so i am getting the draw rect events but for some reason i am using core
> graphics wrong or didn't set it up right to be used
>
> does this make sense to anybody?
>
>
> thanks,
>
> bill
>
>
>
>
>
>
>
>
>
> On Tue, Apr 27, 2010 at 1:41 PM, Uli Kusterer
> <email@hidden<mailto:email@hidden>>wrote:
>
>> On 27.04.2010, at 00:10, Bill Appleton wrote:
>>> i added flush window to the drawRect method -- no help
>>>
>>> it IS calling draw rect right before the window is shown & then you see
>> it
>>> --- all white
>>
>> Oh, also: if your code throws exceptions, those can abort important
>> processes like redraws, you may want to set breakpoints on C++ throws and
>> objc_exception_throw and see if any of these gets triggered and by whom.
>> Also, throwing C++ exceptions through C or ObjC code and ObjC exceptions
>> through C or C++ code can royally screw you.
>>
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> http://www.masters-of-the-void.com<http://www.masters-of-the-void.com/>
>>
>>
>>
>>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden<mailto:email@hidden>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com<http://lists.apple.com/>
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden<mailto:email@hidden>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden