|
Post by vovchik on Jun 17, 2020 21:37:06 GMT 1
Dear Peter,
That fix works both for Pi and Mint19. I do get a warning, though:
In file included from peter-cdkdemo1.bac:51:0, from peter-cdkdemo1.bac.c:2: ./peter-cdkdemo1.bac.gui.h: In function ‘__b2c__guiDefine’: ./peter-cdkdemo1.bac.gui.h:46:51: warning: passing argument 8 of ‘newCDKScroll’ from incompatible pointer type [-Wincompatible-pointer-types] scroll = newCDKScroll(screen,43,18,RIGHT,10,20,"",item,4,TRUE,A_BOLD,1,1); ^~~~ In file included from /usr/include/cdk/alphalist.h:58:0, from /usr/include/cdk/cdk.h:292, from peter-cdkdemo1.bac:4, from peter-cdkdemo1.bac.c:2: /usr/include/cdk/scroll.h:81:12: note: expected ‘char **’ but argument is of type ‘const char **’ CDKSCROLL *newCDKScroll (
The resulting binary works fine. And it looks good. Thanks!!!
With kind regards, vovchik
UPDATE: To get rid of the warning, I modded the last line of the gui definition (arg 8), forcing a char** cast for "item":
{ type=scroll name=scroll args=screen,43,18,RIGHT,10,20,\"\",(char**)item,4,TRUE,A_BOLD,1,1 callback=KEY_ESC,esc }")
|
|
|
Post by bigbass on Jun 18, 2020 3:33:22 GMT 1
Hello Peter and vovchik
Its working for me
the cast that vovchik suggested will allow for a clean compile (thanks)
but it got me thinking about getting values back later
the callbacks are still just experimental using esc
but this would work to to get values from the items and quiet the compiler also hope it could be useful in your design
change the declare to a 2D
DECLARE item[4][15] = { "one", "two", "three", "four"} TYPE char* PRINT "get item ", item[3] FORMAT "%s%s\n"
Joe
|
|
|
Post by rikky on Jun 18, 2020 13:53:12 GMT 1
Installed libcdk5-dev and libcdk5. added PRAGMA OPTIONS -I/usr/include/cdk modded { type=scroll name=scroll args=screen,43,18,RIGHT,10,20,\"\",(char**)item,4,TRUE,A_BOLD,1,1 callback=KEY_ESC,esc }")
And ehhm .. It works. ;°)
I'm verry happy.
|
|
|
Post by Pjot on Jun 18, 2020 18:30:23 GMT 1
Thanks all,
I have added the OPTIONS line to the CDK backend implementation, so after the last fossil update the PRAGMA OPTIONS line should not be necessary anymore.
Regarding the cast to (char**), this is a different story. It seems there are several versions of libCDK and apparently, they differ in their typecasting. On my machine I am using a version from january 2016, while Mint uses a version from december 2016 (more recent).
So hopefully this will be sorted out over time.
Regards Peter
|
|
|
Post by vovchik on Jun 20, 2020 21:45:57 GMT 1
Dear all, Here is another simple animation (gtk2/3). I'll have to try something with gifs soon. With kind regards, vovchik Attachments:
djt-animation.tar.gz (3.58 KB)
|
|
|
Post by rikky on Jun 21, 2020 8:43:44 GMT 1
There are two things wrong with the program. Firstly , when I run the program, it does work fine for a few minutes, but then slows and slows, and eventually, after about 4 to 5 minutes the whole system stucks, and I have to restart. something is eating resources. And the second thing I have removed. I should not ventilate my anger at the world on the BaCon blog. I'am sorry. Rik.
|
|
|
Post by vovchik on Jun 21, 2020 11:14:36 GMT 1
Dear Rik,
Thanks for testing. I ran it through valgrind and see that there is indeed a problem with some memory not being released, although I haven't experienced any system freezes myself. I basically use the same template with all the gtk image animations/changes, so I wonder why this is happening. Peter might have some insights. I wonder whether something is not quite right with my SVG_BUFF function in that respect, or in the timeout handling. Any ideas?
With kind regards, vovchik
|
|
|
Post by alexfish on Jun 21, 2020 12:49:07 GMT 1
Hi Vovchik From what I see. I do not see any reference to free the pix-buf if the sequence has internally refed the pix buff then the buffer has to be freed the free should happen directly after the renderif the object buff has not been refed then it will need to be refed with 'g_object_ref(obj)' first. try unref with the g_object_unref(obj) first and see what happens. beyond that , added your gdk may also have 'g_clear_object(obj)' docs gobject-memoryalso looking at . The function is passing a pixbuf without reference to it the the funtion UPDATE this line CALL GUISET(id, "image", "pixbuf", SVG_BUFF(djt$[pic])) FUNCTION SVG_BUFF(STRING svg$) ' ------------------ LOCAL pixloader TYPE GdkPixbufLoader* LOCAL pixbuf TYPE GdkPixbuf* LOCAL size TYPE NUMBER LOCAL res TYPE int LOCAL raw_array TYPE unsigned char* size = LEN(svg$) raw_array = (unsigned char*)svg$ pixloader = gdk_pixbuf_loader_new() res = gdk_pixbuf_loader_write(pixloader, raw_array, size, 0) res = gdk_pixbuf_loader_close(pixloader, 0) pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader) RETURN pixbuf END FUNCTION
' ------------------ FUNCTION UPDATE() ' ------------------ LOCAL pic TYPE int pic = VAL(TOKEN$(seq$, x + 1)) CALL GUISET(id, "image", "pixbuf", SVG_BUFF(djt$[pic])) INCR x IF x = 4 THEN x = 0 RETURN TRUE END FUNCTION BR Alex
|
|
|
Post by rikky on Jun 21, 2020 13:33:13 GMT 1
From the Bac-rot package from last page, I have now ALL 5 programs simultaneously running for 19 minutes and counting. No problems whatsoever. the difference is that those programs are rotating a label, and this one is rotating an image. So indeed the pixbuf sub seems to be the culprit.
|
|
|
Post by vovchik on Jun 21, 2020 14:09:22 GMT 1
Dear Alex and Rik, Thanks for the testing and advice. I am trying to figure out the memory issue with SVG_BUFF. Here is another version, with various g_object_unref instances for pixbuf. When I try to unref pixloader, however, I get a bomb. Any ideas? With kind regards, vovchik
|
|
|
Post by alexfish on Jun 21, 2020 14:59:49 GMT 1
Hi Vovchik Have taken out what you have done and updated the UPDATE Functions. Now you need to set up same for other image functions IE get pixbuf, draw it and free it hope this will help to get started BR Alex
|
|
|
Post by rikky on Jun 21, 2020 15:14:51 GMT 1
I don't get any 'bomb'
Runned the program for 18 minutes, and then by accident closed it. No problems whatsoever.
So it seems the 'g_object_unref(pixbuf)' in the UPDATE() did the trick.
|
|
|
Post by alexfish on Jun 21, 2020 15:17:59 GMT 1
Hi Vovchik
I re - implemented the pix loader close
' ------------------ FUNCTION SVG_BUFF(STRING svg$) TYPE GdkPixbuf* ' ------------------ ' use global to free later LOCAL pixloader TYPE GdkPixbufLoader* ' use global to free later LOCAL pixbuf TYPE GdkPixbuf* LOCAL size TYPE NUMBER LOCAL res TYPE int LOCAL raw_array TYPE unsigned char* size = LEN(svg$) raw_array = (unsigned char*)svg$ pixloader = gdk_pixbuf_loader_new() res = gdk_pixbuf_loader_write(pixloader, raw_array, size, 0) res = gdk_pixbuf_loader_close(pixloader, 0) pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader) gdk_pixbuf_loader_close(pixloader, NULL) RETURN pixbuf END FUNCTION
BR Alex
|
|
|
Post by vovchik on Jun 21, 2020 15:31:10 GMT 1
Dear Alex,
Thanks. I now inserted all the pixbuf business before and after each call to SVG_BUFF but still see this in valgrind:
==23558== LEAK SUMMARY: ==23558== definitely lost: 93,280 bytes in 160 blocks ==23558== indirectly lost: 331,749 bytes in 8,692 blocks ==23558== possibly lost: 19,189 bytes in 42 blocks ==23558== still reachable: 4,776,173 bytes in 18,101 blocks ==23558== of which reachable via heuristic: ==23558== length64 : 5,280 bytes in 75 blocks ==23558== newarray : 1,824 bytes in 34 blocks ==23558== suppressed: 0 bytes in 0 blocks ==23558== ==23558== For counts of detected and suppressed errors, rerun with: -v ==23558== ERROR SUMMARY: 69 errors from 57 contexts (suppressed: 3 from 1)
I am now cheking the valgrind output to see what it does not like:
valgrind --track-origins=yes --leak-check=full --show-leak-kinds=all ./djt-45-gtk2-memtest-alex
It would be nice to get rid of those leaks....
With kind regards, vovchik
|
|
|
Post by alexfish on Jun 21, 2020 15:58:48 GMT 1
Hi Vovchik
Can you post the updated code
but I be puzzled at this one
==23558== still reachable: 4,776,173 bytes in 18,101 blocks ==23558== of which reachable via heuristic: ==23558== length64 : 5,280 bytes in 75 blocks ==23558== newarray : 1,824 bytes in 34 blocks
just kind of thinking of the raw array done in bacon
size = LEN(svg$) raw_array = (unsigned char*)svg$
Just a thought
ADDED
having a problem with charset in the text
CALL GUISET(id, "label", "label", "<span color='darkorange' font='24' weight='800'>🞄🞄🞄 STABLE GENIUS 🞄🞄🞄</span>")
this big DOTS do not show
also have you checked oth gtk 2/3 apps with manipulation in
have vague recollections of gtk apps in generally show a memloss.. in valgrind
BR Alex
|
|