The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

This is a very rare situation to reproduce. I am getting an error in SDL_UpdateTexture. The call to SDL_GetError() returns :

LockRect(): INVALIDCALL

I only found the condition if SDL_CreaterRenderer is called with SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the problem is that SDL application has no focus, but is in foreground and the system comes out of display turned off by power saving and also having a screen saver.

The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia card. I have found no problem using software renderer so far.

Any on how to recover from that condition ?

Thanks

if you use SDL_gfx, but initialize/close SDL in your application, characters drawn with sdl_gfx will be garbled.

basically, the gfx library keeps a list of textures for each drawn character. This list is initialized on-the-go whenever a character is first used : first usage will do a slow draw to a surface, which is then stored as a texture for subsequent, much faster drawing.

closing SDL will destroy the renderer and all associated textures, but SDL_gfx doesn’t know this !

I recommend calling

gfxPrimitivesSetFont(NULL,0,0);


right before you destroy your renderer or close SDL. This will destroy all the temporary textures.

I hope this helps anyone in the future :-)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dear Jeroen,

I do not use SDL_gfx .


Thanks 
Armando


On Tue, Oct 6, 2015 at 11:51 AM, jeroen clarysse wrote:

I wonder if it would help add-on library developers to have an event/callback that signals that SDL has quit?  Or one could check WasInit all the time... :-/

Jonny D




On Tue, Oct 6, 2015 at 11:16 AM, Armando Alaminos Bouza wrote:

Dear Jonny. 
Is this related with the problem I described at the start of this thread ? Is it possible that SDL quits?  I was supposing that the texture was freed or discarded without my knowledge but not the entire SLD.

Thanks


On Tue, Oct 6, 2015 at 12:34 PM, Jonathan Dearborn wrote:

I'm not sure which problem you refer to.  Can you link to it?  The problem in this particular thread is when you explicitly call SDL_Quit() and then use SDL_gfx later.  If you don't use SDL_gfx, this does not apply to you.

Jonny D


On Tue, Oct 6, 2015 at 12:01 PM, Armando Alaminos Bouza wrote:

It is at the very beginning of the thread, but this is the quote
-----------------------------------------------
This is a very rare situation to reproduce. I am getting an error in SDL_UpdateTexture. The call to SDL_GetError() returns :

LockRect(): INVALIDCALL

I only found the condition if SDL_CreaterRenderer is called with SDL_RENDERER_ACCELERATED, but not with software renderer.
A lot of machine configurations do not generate the error condition.
On the PC with the problem there are two monitors. The trigger of the problem is that SDL application has no focus, but is in foreground and the system comes out of display turned off by power saving and also having a screen saver.

The target PC runs Windows 7, 64 bits (my app is 32 bits). It has a NVidia card. I have found no problem using software renderer so far.

Any on how to recover from that condition ?
--------------------------------------


On Tue, Oct 6, 2015 at 1:23 PM, Jonathan Dearborn wrote:

Then this thread got mixed up somehow with yours.

Jonny D


On Tue, Oct 6, 2015 at 12:33 PM, Armando Alaminos Bouza wrote:

Jonathan Dearborn writes:


Jeroen's mail with the subject "a short warning about SDL_gfx" was sent
as a reply to Armando's mail with the subject "Problem with
SDL_UpdateTexture when coming form screen saver" (according to the mail
headers). Thus any "correctly" behaving email client will believe that
Jeroen's mail was intended as a direct reply to Armando's question.

So yes, you could say that these threads got mixed up somehow.

eirik

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

There we go.  Well then Gmail is (probably intentionally) misbehaving because it groups by subject line.

Jonny D


On Tue, Oct 6, 2015 at 1:23 PM, Eirik Byrkjeflot Anonsen wrote:

well, it was my fault : I just replied, but changed the mail title to start a new thread. I didn’t realize that a mail could have some sort of hidden ‘thread identifier’ and thought only the mail title was used

my apologies :-(




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No problem !

But if any one has some inside into my problem I will greatly appreciate.
Fortunately, I have tested several times and there is no problem if using the software renderer.
On the other hand, the hardware rendered is also creating problems with some Windows XP, specially if inside a virtual machine.
So, I will be using the software renderer as default and the user can change that in a configuration file.

Thanks.

jeroen clarysse writes:


It's a fairly common mistake these days. Sufficiently common that:


Yes, that probably is intentional.

I think the problem is really that many of these systems were made by
"logical" people (by which I mean people who would never press a "reply"
button unless they actually intended to reply to something). But most
people are not that "logical" (by which I mean that they don't consider
the meaning behind what they do as long as the end result "looks
right").

I'm afraid we "logical" people are on the losing side here and will just
have to adjust. So don't worry too much about it :)

Still, just knowing why things end up the way they do might be useful
occasionally. Or at least a little bit interesting. And that's really
why I sent my explanation.

eirik

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Most likely this is because D3D is dumping your textures.  This can happen on certain mode switches, which might be what you're seeing when you come back from the screen saver.

To resolve this, you have to handle the SDL_RENDER_DEVICE_RESET event by reloading your textures (from memory or disk).  I think that event was only implemented as of SDL 2.0.4.


Have you tried the OpenGL renderer to see if that works better for your needs?



Jonny D




On Tue, Oct 6, 2015 at 2:28 PM, alabouza wrote:

Yeah, (off topic at this point) but I would actually say it's a failing of the client UI.

The client may not present the necessary information to the user for him to know which thread the new message will be a part of.  If the client organizes incoming mail by subject line, then shouldn't it also do the same for outgoing mail (by adjusting the hidden data accordingly)?


UX speaking, when you want to change the subject of a discussion with the same target email address, should you be expected to leave the discussion, create a new message, and input the email address again?


Jonny D





On Tue, Oct 6, 2015 at 2:50 PM, Eirik Byrkjeflot Anonsen wrote:

Hi Jonny. Thanks for sharing your ideas. I will explore your solution using SDL_RENDER_DEVICE_RESET. The content of my textures is all stored in memory.

Armando


----------------------------
Most likely this is because D3D is dumping your textures. This can happen on certain mode switches, which might be what you're seeing when you come back from the screen saver.
To resolve this, you have to handle the SDL_RENDER_DEVICE_RESET event by reloading your textures (from memory or disk). I think that event was only implemented as of SDL 2.0.4.

Have you tried the OpenGL renderer to see if that works better for your needs?


Jonny D