Bug #3869
closedErrors when drawing MDI window backgrounds should be ignored
0%
Description
Detaills:
Out of memory.
Void CheckErrorStatus(Int32)
at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
at System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y)
at System.Drawing.Graphics.DrawImageUnscaled(Image image, Int32 x, Int32 y)
at AdiIRC.GUI.MainForm.MdiClientOnPaint(Object sender, PaintEventArgs e)
at System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.MdiClient.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)How it happened: My notebook was in sleeping mode. So, after i turned it on to the normal mode, the crash happened. The picture window does have a background, and AdiIRC has not been able to recognize it at the moment of the crash for some reason related with ram memory.
Do you remember this? https://dev.adiirc.com/issues/3864
Looks like this issue does have a direct or indirectly relation with that other issue. AdiIRC should not try load an image if somehow is unable to recognize it due an unexpected failure or if someone set a non-existing file in a picture window.
Updated by Per Amundsen about 6 years ago
- Category set to Interface
- Status changed from New to Resolved
- Assignee set to Per Amundsen
This issue is not related to picture windows, but to drawing the background image in the MDI area (behind the windows).
Background images are always kept in memory and not loaded from files, they are repainted as needed so it's not possible for it to go "out of memory".
This type of crash is a catch all for all kinds of drawing issues, including display driver bugs, I have seen similar bugs in other programs and places related to waking from sleep/adding or removing monitors/updating display drivers.
Due to the unknown cause of the crash and possible not adiirc related at all, I have added a check that just silence it for next beta.
Also there is no relation to https://dev.adiirc.com/issues/3864.
Updated by Per Amundsen about 6 years ago
- Subject changed from Crash in picture window to Errors when drawing MDI window backgrounds should be ignored
- Status changed from Resolved to Closed
Updated by Cassio Luz S. about 6 years ago
Per Amundsen wrote:
This issue is not related to picture windows, but to drawing the background image in the MDI area (behind the windows).
Background images are always kept in memory and not loaded from files, they are repainted as needed so it's not possible for it to go "out of memory".
This type of crash is a catch all for all kinds of drawing issues, including display driver bugs, I have seen similar bugs in other programs and places related to waking from sleep/adding or removing monitors/updating display drivers.
Due to the unknown cause of the crash and possible not adiirc related at all, I have added a check that just silence it for next beta.
Also there is no relation to https://dev.adiirc.com/issues/3864.
Interesting
Thanks for the corrections and for your attention
Updated by Cassio Luz S. about 6 years ago
Per Amundsen wrote:
Background images are always kept in memory and not loaded from files, they are repainted as needed so it's not possible for it to go "out of memory".
By the way, i have an ask:
Images or icons in dialogs are kept in memory as well?
Updated by Per Amundsen about 6 years ago
Yes, the image/icon is loaded into memory from the file once when creating the "picture box/area", and then just repainted as needed after that onto the surface.
Updated by Cassio Luz S. almost 6 years ago
Per Amundsen wrote:
Yes, the image/icon is loaded into memory from the file once when creating the "picture box/area", and then just repainted as needed after that onto the surface.
But for example, if I load 3 different pictures into one control along a period of time, the dialog will cache all them?
Example:
The control is: icon 1000, 10 10 200 200
And so, i load 3 different pictures in this control:
/did -g <dialog> 1000 <file1.png>
30 seconds later: /did -g <dialog> 1000 <file2.png>
60 seconds later: /did -g <dialog> 1000 <file3.png>
In this case, if I loaded file3.png and i want back to load file1.png, is file1.png cached? (due i loaded file1.png before)
Also, does AdiIRC clean the cache when the dialog gets closed in a current AdiIRC session?
Updated by Per Amundsen almost 6 years ago
it's not a cache in that sense, when you use /did -g, AdiIRC opens the file and makes a copy of the image which it stores in a variable in the "picture box", when doing /did -g with a new file, it then open that file, makes a copy of that image and removes the previous image.
It's up to the .NET garbage collection to remove it from memory but it typically happens instantly in these cases, so no the previous image is not cached and doing /did -g will open the file and make a different copy each time.
You can think of it like /var %image = image, the next time you use /var %image it overrides the previous value and the previous value is lost.
Updated by Cassio Luz S. almost 6 years ago
I see
By the way, it's interesting that depending for what purpose a tool is projected, a cache might not be exactly good. If the files gets modifield, the client would show the cache instead the modifield files (at least in a current session)
Updated by Per Amundsen almost 6 years ago
The file would be locked in that case and you can't modify a locked file, so that doesn't matter.
If the file gets modified just use /did -g again, the image will be make a new copy from the modifed file.
Updated by Cassio Luz S. almost 6 years ago
Per Amundsen wrote:
it's not a cache in that sense, when you use /did -g, AdiIRC opens the file and makes a copy of the image which it stores in a variable in the "picture box", when doing /did -g with a new file, it then open that file, makes a copy of that image and removes the previous image.
It's up to the .NET garbage collection to remove it from memory but it typically happens instantly in these cases, so no the previous image is not cached and doing /did -g will open the file and make a different copy each time.
You can think of it like /var %image = image, the next time you use /var %image it overrides the previous value and the previous value is lost.
The behavior is the same for a picture loaded by default into a control? icon 1000, 10 10 200 200, <default.png>
Updated by Per Amundsen almost 6 years ago
Not sure I understand the question, the "cache" behavior is the same in every place AdiIRC uses images, same as most programs who uses images, nothing special about AdiIRC here.
Updated by Cassio Luz S. almost 6 years ago
Per Amundsen wrote:
Not sure I understand the question, the "cache" behavior is the same in every place AdiIRC uses images, same as most programs who uses images, nothing special about AdiIRC here.
I see. Thanks.