Home » Community » U++ community news and announcements » 2019.2 rc5
|
Re: 2019.2 (pre)released [message #52563 is a reply to message #52558] |
Tue, 22 October 2019 12:51 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
mirek wrote on Tue, 22 October 2019 12:51Tom1 wrote on Tue, 22 October 2019 11:47They both (ib and bpainter) are actually members of different classes, but both classes are continuously alive throughout the life of the window.
BR,
Tom
Would it be possible to test with temporary ib? Just to get some clues...
Also, obvious reason, is not it possible that bpainter gets used (any method called) between ib being resized and Create called? (As in it would be referencing old data of ImageBuffer).
Is Finish called properly?
Mirek
Temporary ib would change the rendering in a big way as it is my base for getting Paint and Render separated.
While that would be a sensible explanation for what is happening here, I do not think it is possible for bpainter to be used when ib is out-of-order after resizing. As you can see from the testcase, Layout doing ib.Create calls Render doing bpainter.Create(ib) immediately.
Best regards,
Tom
|
|
|
Re: 2019.2 (pre)released [message #52564 is a reply to message #52549] |
Tue, 22 October 2019 12:55 |
Oblivion
Messages: 1091 Registered: August 2007
|
Senior Contributor |
|
|
Quote:
OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well.
Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags.
https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/
Mirek
https://github.com/clearlinux/clr-installer/pull/545
My workaround was to suppress the message in CtrlCore/Gtk.h
This should be qualified though. IMO the auppression should be disabled in release mode.
#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif
#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>
#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif
Best regards,
Oblivion
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Tue, 22 October 2019 12:56] Report message to a moderator
|
|
|
|
Re: 2019.2 (pre)released [message #52569 is a reply to message #52564] |
Tue, 22 October 2019 14:22 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Oblivion wrote on Tue, 22 October 2019 12:55Quote:
OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well.
Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags.
https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/
Mirek
https://github.com/clearlinux/clr-installer/pull/545
My workaround was to suppress the message in CtrlCore/Gtk.h
This should be qualified though. IMO the auppression should be disabled in release mode.
#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif
#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>
#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif
Best regards,
Oblivion
Thank you, applied. I am not much worried about release here... This is temporary solution until the next release anyway.
|
|
|
Re: 2019.2 (pre)released [message #52570 is a reply to message #52566] |
Tue, 22 October 2019 14:33 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
Thanks for your prompt action on this. Now I have already left the office for today, but I will test it as soon as I get back there tomorrow.
Thanks and best regards,
Tom
|
|
|
Re: 2019.2 (pre)released [message #52577 is a reply to message #52566] |
Wed, 23 October 2019 08:34 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
mirek wrote on Tue, 22 October 2019 14:51Tom1 wrote on Tue, 22 October 2019 12:20Hi,
Thanks! I will look into your suggestions next.
Meanwhile, here's a "crashable" testcase:
Hopefully fixed - does not crash in trunk anymore.
Can you please check the trunk in your application?
Mirek
Thanks Mirek! The fix works perfectly.
Best regards,
Tom
|
|
|
Goto Forum:
Current Time: Fri Mar 29 07:54:39 CET 2024
Total time taken to generate the page: 0.01691 seconds
|