search

game-stop / veejay

Veejay is a visual instrument and realtime video sampler (for live video improvisation)
http://veejayhq.net
82 stars 11 forks source link

Reloaded - Gtk3 migration #163

Open d-j-a-y opened 6 years ago

d-j-a-y commented 6 years ago

https://github.com/d-j-a-y/veejay/commits/djay_gtk3

Reloaded specific

General Stuff Preparation in GTK+ 2.x

Do not include individual headers Do not use deprecated symbols Use accessor functions instead of direct access Replace GDK_ with GDKKEY Use GIO for launching applications Use cairo for drawing

Changes that need to be done at the time of the switch

Replace size_request by get_preferred_width/height Replace GdkRegion by cairo_region_t Replace GdkPixmap by cairo surfaces Replace GdkColormap by GdkVisual GdkDrawable is gone Event filtering Backend-specific code GtkPlug and GtkSocket The GtkWidget::draw signal GtkProgressBar orientation Check your expand and fill flags Scrolling changes GtkObject is gone GtkEntryCompletion signal parameters Resize grips Prevent mixed linkage <--- see https://github.com/c0ntrol/veejay/issues/163#issuecomment-419017672 Install GTK+ modules in the right place

https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html https://developer.gnome.org/gtk3/stable/ch26s02.html https://wiki.ubuntu.com/Lubuntu/Developers/GTK3Migration

After all .... TESTS!

TODO Before release

* Xorg high cpu! For instance, the program might be making resource-intensive xlib calls in a tight loop https://wiki.ubuntu.com/X/Troubleshooting/HighCPU ---- FIX issue exemple Fixed by cfa0a2e988dc56 . See also https://github.com/c0ntrol/veejay/issues/163#issuecomment-435519052

TODO After release

d-j-a-y commented 6 years ago

Prevent mixed linkage

Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported

To determine how the mix is done :

for i in `ldd /usr/local/bin/reloaded | awk '{print $3}'` ; do \
        if [[ `ldd $i | grep gtk` ]] ; then \
           echo -e "$i \n `ldd $i | grep gtk` \n" ; \
        fi ; done

(from milan / https://mail.gnome.org/archives/evolution-hackers/2011-February/msg00003.html )

d-j-a-y commented 6 years ago

Glad to share the reloaded gtk3 first run :-)

reloaded-gtk3-firstrun

At least it's running, and basic stuff is working ...

game-stop commented 6 years ago

Hey that looks nice :)

Still, its a lot of work to tweak the UI :D Some buttons fell off the screen :P

See you!

On Fri, Sep 7, 2018 at 2:55 PM d-j-a-y notifications@github.com wrote:

Glad to share the reloaded gtk3 first run :-)

[image: reloaded-gtk3-firstrun] https://user-images.githubusercontent.com/2943058/45220155-88dbe980-b2ad-11e8-87ba-ed18017dd7ea.jpg

At least it's running, and basic stuff is working ...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/c0ntrol/veejay/issues/163#issuecomment-419430606, or mute the thread https://github.com/notifications/unsubscribe-auth/AHfPfHU2SxzK7A0k7ONOJp-9k1lBa-W9ks5uYmzagaJpZM4WVA-q .

d-j-a-y commented 6 years ago

after a bit of css ....finally ! :-) reloaded-gtk3-fitscreen

d-j-a-y commented 6 years ago

now with a bit of gtk3 theming :-O reloaded-gtk3

pink + green buttons come from tweaks on "reloaded.css"

game-stop commented 6 years ago

Except for the purple it looks good! The feedback checkbox in the top looks a bit odd Do the widgets without a label have a tooltip ? There are a few other windows in reloaded, have you GTK3'd them as well ? Would be nice if you can show those too!

d-j-a-y commented 6 years ago

reloaded-gtk3-curve_ _dialog

feedback

+todolist

tooltips

yep, expect those who did't had ... ;-)

other windows gtk3

yep, but ... still ... the menu is missing and so ... can't test them.

The curve widget look nice, but maybe will need some hack about rounding because, since ever?, the curve has always had trouble with that (hit [ok] several time, the curve will tend to 0 --- #AnotherIssue --- )

d-j-a-y commented 6 years ago

@c0ntrol Theming by rc is broken. Gtk3 already offers to use other theme at runtime for particular app with the environment variable GTK_THEME

Do you think it's necessary to keep the user defined gui definition feature ? (gtk3 fashion is css)

game-stop commented 6 years ago

No, let's not go fix that. Back then, it was more of a hack anyway. Please remove all that has to do with it

d-j-a-y commented 6 years ago

finally ... got (bits of) the menu back ....

gotthemenuback

after unsuccessful try to declare it at runtime ... come back to ressources with gtkmenubar/ gtkmenu / gtkmenuitem /... definitions ... (where it was GtkUIManager / GtkActionGroup / GtkAction ...)

d-j-a-y commented 5 years ago

Menus are back !

https://github.com/d-j-a-y/veejay/tree/djay_gtk3

game-stop commented 5 years ago

Great! Is it ready to be merged ?

d-j-a-y commented 5 years ago

Hummm .... why not ???

some corners to polish ... but should be usable .... (reloaded -a , still broken for example)

But , please can you stress test it ?.... during let's say one week before merging ?

In fact , i really suspect performance issues !

[cpu] [mem]
 65,9 11,2  48:20.32 veejay                       
 42,6  3,0  11:06.20 Xorg                         
 28,5  2,4   0:18.61 reloaded

and without reloaded Xorg consume quite nothing from cpu....

Also, could be a good moment to publicity at this incredible and unique piece of floss code. . . what do you think ? Publish .deb / rpm .... ? submit to packager .... ? maybe too much ... at the same time ...

d-j-a-y commented 5 years ago

Xorg high cpu! For instance, the program might be making resource-intensive xlib calls in a tight loop https://wiki.ubuntu.com/X/Troubleshooting/HighCPU

Has Gtk is build on top of xlib ... i think the issue come from the way reloaded update the gui status.

game-stop commented 5 years ago

status is usually updated at frame rate interval; every 40 ms. is the preview image on ? is there unnecessary redrawing of widgets ? have you tried a profiler? somewhere, too much work is done

d-j-a-y commented 5 years ago

is the preview image on ?

on / off the same

is there unnecessary redrawing of widgets ?

could be ... reloaded has some homebrew widget + now gtk3curve

have you tried a profiler?

nop... i coutch it was xorg eating cpu at the time i wrote the previous comment

somewhere, too much work is done

and reloaded is not the first gtk3 app ;-) so should somehow work!

About building package for distribution, do you know https://build.opensuse.org/ ? a generic system to build and distribute packages from sources

d-j-a-y commented 5 years ago

After fighting against gprof , configure.ac and Makefile.am i'm now able to profile reloaded ....

and

is there unnecessary redrawing of widgets ?

Yep look like it's exactly that ... and coming from gtk3curve :-( ...

hoping it not so hard to fix!!! I have started this work after i found this widget !!!!

d-j-a-y commented 5 years ago

Yep look like it's exactly that ... and coming from gtk3curve :-( ...

Hummm ... i have built and ran reloaded without gtk3curve .... xorg still > 50 % ! :-(

game-stop commented 5 years ago

Please try:

just an update on gtk3curve:

in your djay_gtk3 branch, the gtk3_curve_motion_notify_event implementation does not set a return value at the end of the function, possibly this gives unexpected problems.

Also, the implementation of gtk3curve does not seem to follow the recommendations on https://developer.gnome.org/gtk3/stable/ch01s05.html to use a backing surface for redrawing (gdk_window_create_similar_surface ) but I could be wrong (only glimpsed at it)

d-j-a-y commented 5 years ago

(last edit 01/11 - 19h) Starting veejay $veejay -f 2 -g my_video.avi (great tips thanks!) , i have found something very interesting !!!! :

Finding where and why could solve most part of the performances issue :-)

Nota : i still suspect some leak of performances from gtk3curve __ i already remove some gtk_widget_queue_draw __ and possibly also from gtktimeselection.

d-j-a-y commented 5 years ago

A(nother) cguru just gave me a fresh look to cpu issue... going deep //// quite to the roots .

We found wired behaviour in time calculation when preview is not enabled . And actually i have the feeling that the wired behaviour start to happen after the sequencer get a preview image (or multitrack).

I share a branch with some printf to have a look ...

veejay -f 2 -g myvideo.avi & First reloaded -P 2 -p 3490 wait 30 seconds , then reloaded -p 3490 wait 30s and compare the output.

Wired behaviour isn't it ?

game-stop commented 5 years ago

This behaviour, that is with the gtk3 reloaded ? Please elaborate on the weird behaviour, what are you expecting?

the gveejay_time_to_sync function should return a 1 when its time to pull data from veejay. how to fix this, I will need to dive in it - haven't visited that code in a long time. It could be that, there is a lag due to the amount of data veejay sends (veejay creates the preview image, in raw format (?) , in JPEG ? and sends that over the socket)

If i remember correctly, the sequencer is another thread that pulls data from veejay , it is possible something stupid is happening there

d-j-a-y commented 5 years ago

Xorg eating cpu!

https://github.com/c0ntrol/veejay/commit/cfa0a2e988dc56e776c854faa2212bc24a8e3e69 did it !

When preview is on, only one printf each 0.5s (fps=2) ... when preview off , after 2s the console is flooded each 0.5s

The cause of the problem is that, after sleeping for a short time, a call to gveejay_update() happens and this flow triggers (unnessary?) updating of the UI

I cleaned up the function and put some comments in it

The function gveejay_to_time_sync should actually throttle the number of times the UI is updated. It is supposed to go into sleep, when it is not yet time to update the UI

When the preview is enabled, it is ALWAYS time to update the UI (it always hits the return 1) When the preview is disabled, it is ALWAYS time to sleep and as it didnt sleep very long, a call to gveejay_update() happens immediately after, causing the xorg cpu usage.

Every (seconds per video frame) a new status line is available, but due to bad timing info in the gveejay_time_to_sync function, the UI is updated twice, or thrice, or even more often using the same status lines as before. So, that is unncessary redrawing of widgets

What follows is that, the gveejay_update() may do too much work. It also updates widgets that are currently not visible and/or it may update widgets that have not changed

d-j-a-y commented 5 years ago

cfa0a2e did it !

But ... as side effect, when the video is normal fps, the time bar is not moving smoothly ... :-(

game-stop commented 5 years ago

nsec (time to wait before next update) must be calculated more precisely, i can take a look at this sometime this weekend

d-j-a-y commented 5 years ago

https://github.com/d-j-a-y/veejay/tree/djay_gtk3 Updated !

This branch is 52 commits ahead of c0ntrol:master Latest commit b6a42f7 an hour ago

game-stop commented 5 years ago

Reloaded GTK3 has been refactored

Most important changes:

Issue need to be reviewed to see what work is left

game-stop commented 5 years ago

Updated issue:

game-stop commented 5 years ago

Refactor how widgets are updated. Currently, there are too many unnecessary updates happening initiated from the periodic update flow. Especially visible in top when the FX tab is open, compared to when SEQ tab is open.

game-stop commented 5 years ago

Another issue is that drawing 16 GtkScale widgets in the FX panel causes 30% CPU usage (even when these GtkScale widgets are not sensitive) in combination with the reloaded CSS

This issue is in GTK, different versions, different results. Added optional '--faster-ui' commandline option if your GTK version has this special feature.

game-stop commented 5 years ago

Update issue:

game-stop commented 5 years ago

Screenshots: image image image image

game-stop commented 5 years ago

image image image

game-stop commented 5 years ago

issue can be closed ?

d-j-a-y commented 5 years ago

still some minor stuff ...