|
|
User login
Feeds |
Direct Screen Access goes wrong when menu/dialog appears
|
|||||
| Wed, 2004-12-08 12:40 | |
|
Hi,
Anyone else seen this happen ? The CDirectScreenAccess class works fine for task-switching, calls AbortNow() and Restart() as its supposed to - and there I can call Cancel() & StartL(). However, try plugging in the phone charger or pressing the menu softkey.. AbortNow() will still be called, but this time when I call StartL() again - the screen display is all messed up : half of it is not being updated, and the top part of my application is being drawn about halfway down the screen. Anybody else observed this happening, or have a solution for it? Perhaps I'm doing something wrong (although I took my implementation directly from the Nokia Direct Screen Access example). Does this problem sound familiar to anybody? Help would be much appreciated, as I've tried many things now to fix it but I'm stumped.. CW |
|
Forum posts: 69
Glad to hear someone else has this problem too!
However I've tried various games on the N-Gage, and they don't have the problem - you can plug in & out the battery recharger and the dialog appears, but it doesn't mess up the screen.
So if this *is* a bug with series 60, there must be some way around it!!
CW
Forum posts: 69
Forum posts: 6
After a system dialog was displayed, Symbian took a dislike to me accessing the DataAddress() from the other thread (although all access was controlled by semaphores).
I've now switched to using shared memory-buffers instead of CFbsBitmap's and everything is fine.
Forum posts: 6
You should only call DataAdress() on your CFbsBitmap at object construction and never ever afterwards. This is why N-Gage games work properly.
Forum posts: 6
I'm very puzzled though - I don't remember reading that in the documentation; do you have a link to the SDK help section?
I also don't see why this would be so, and for what reason it should not be possible to call DataAddress() at will. Do you mean that this function should only be called within the constructor of a derived class, or is it safe to use it immediately after the bitmap's construction?
Some other graphics API's hide the fact that bitmap memory may be internally reallocated or moved, by using a Lock()/Unlock() syntax. Surely Symbian would have implemented something similar if it there was any reason why the data chouldn't be freely accessed at will?
Incidentally, I have used the DataAddress() function quite frequently during the course of a program before without any problems - but it was only when I tried to do this across threads that I ran into this issue...
Many Thanks
CW
Forum posts: 6
You are right, the memory could be reallocated in some circumstances, but we never experienced that. There is also no hint in the SDK help on this. It is just our experience.
We had that problem also in a single threaded application on an N-Gage QD.
Forum posts: 205
What do you mean by "wrong memory pointer"? You need to know that this adress can change in run-time. and BTW i use this function on n-gage and it works great.
Best regards,
Michal Laskowski
Forum posts: 6
The only thing I was doing which could have caused this problem, was to use a bitmap in one thread which had been created from within another thread.
CW
Forum posts: 11
If i plug the charger, the app errors (app closed). How do i solve this problem?
Thanks
www.l2tool.com
Forum posts: 11
I tested with the charger (more than 10 times) the screen displays properly.
www.l2tool.com
Forum posts: 9
I have the same problem...
I draw to the whole screen by using the view class. I get the window associated to the view and system gc and do a bit blit from an offscreen-bitmap.
That works fine, everything is in place UNTIL I press the left softkey and the usual pop-up menu appears. When I cancel it, the image blitted to screen is shifted downwards. Only the portion of the screen that the menu took up, gets now updated. The upper portion is left untouched and is not updated.
When I start up the Series60 emulator and the first thing I do is launch my application, the problem does not occur. Only when I close the application and re-launch it in the same emulator-session, the problem starts.
The problem also appears when I the press the "application" button, start another application in the meantime and later return to my still-running first application.
The appearance of the problem is the same on emulator and on phone ( Nokia 6600 ).
I would be happy for any help/suggestions!!
Victor
Forum posts: 1
Andit looks like that the iGc->DrawingRegion
changed to the region of popmenu or infobox.
If you check the region of a infobox when charge plugin the region boundbox
become a (0,44,176,110) not (0,44,176,188)as normal.
I used bitmap dataAdress too at construct .
Im sure if you can change the iGc->DrawingRegion you can resolve this.(but it looks like very hard )
Or if you can get adrss just before use.
Forum posts: 1273
The most important information I have is this:
The call to DataAddress MUST ALWAYS be called between LockHeap and UnlockHeap and the value returned must NEVER be used outside those in any way.
The bitmap WILL move, and will do this at points you can NEVER predict.
If it have seemed to work without following the above, you have just been "lucky".
Forum posts: 1273
The region returned by DrawingRegion is the region where you are safely allowed to draw. That is, the area of your window/view that is not covered by the menu/popup.
You should ALWAYS respect this region, or you could just as well skip useing DSA all together, and just grap the framebuffer pointer from HAL. (wich ofcourse will work crap, just as it will if you ignore the region returned by DSA)
If you do not want to draw when not your entire view is visible (maybe your render code doesn't support to draw to subregions), then you should check the region so that it matches what you expect.