Bug 275665 - Interface box resized in Wireshark-1.6.0
Summary: Interface box resized in Wireshark-1.6.0
Alias: None
Product: Oxygen
Classification: Plasma
Component: gtk2-engine (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
Depends on:
Reported: 2011-06-14 23:07 UTC by nucleo
Modified: 2011-07-29 23:25 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description nucleo 2011-06-14 23:07:01 UTC
Version:           unspecified (using KDE 4.6.4) 
OS:                Linux

Interface box in "Capture options" resized almost every time after window opened in Wireshark-1.6.0 and oxygen-gtk-1.1.0 (no such problem with oxygen-gtk-1.0.5)
Just after window opened it looks smaller than "Capture filter" box but then becomes the same size.
This happens even if animation code removed http://pastebin.com/raw.php?i=gG3NCwHL

Reproducible: Always

Steps to Reproduce:
1. Start Wireshak
2. Press "Show the capture options" button

Actual Results:  
Sometimes size of  Interface box the same as "Capture filter" box but next time it smaller after window opened.

Expected Results:  
Size of Interface box in should not change.

Note that window with warning about adding user in wireshark group should not appear. If this window with warning opened before  "Capture options" then will be no problems in "Capture options" window.
Comment 1 Hugo Pereira Da Costa 2011-06-14 23:32:04 UTC
This is not due to the combobox list resize hook.
This is due to our "group box" hack (just compare the appearance of the incriminated dialog 'boxes" between 1.0 and 1.1. You'll see that 1.1 is much closer to what it would look with Qt, but the window resize you experience is the price to pay for this).

I'll add an option in CMakeLists to disable that at compilation time (since there is no such thing).

The right code to prevent this is:

--- a/src/animations/oxygenanimations.cpp
+++ b/src/animations/oxygenanimations.cpp
@@ -317,7 +317,7 @@ namespace Oxygen
         if( GTK_IS_NOTEBOOK( widget ) )
             gtk_notebook_set_show_border( GTK_NOTEBOOK(widget), FALSE );
-        if( GTK_IS_LABEL( widget ) &&  GTK_IS_FRAME( gtk_widget_get_parent( widget ) ) )
+        if( false && GTK_IS_LABEL( widget ) &&  GTK_IS_FRAME( gtk_widget_get_parent( widget ) ) )
             GtkFrame *frame( GTK_FRAME( gtk_widget_get_parent( widget ) ) );

But I will not commit it, cause it does really look worse than now IMO
Comment 2 nucleo 2011-06-14 23:41:16 UTC
So, you think that this annoying window resizing not a bug?
Comment 3 Hugo Pereira Da Costa 2011-06-14 23:50:35 UTC
Well. It's not a bug in the sense that it is "intended", as being the only way we can implement Qt like groupboxes. You can prevent the "bug" by disabling this implementation and reverting to the old (inconsistent) implementation of these boxes (the so-called GtkFrame). 

We decided that the resize issue was a "small enough" price to pay to have the nice groupboxes, since you can't have both (that is: nice groupboxes, and no resize bug). 

Does that make sense ?
Comment 4 Hugo Pereira Da Costa 2011-06-14 23:54:22 UTC
did you try the small patch I sent ? 
And if yes, what is your personal opinion between the two different rendering of the incriminated dialogs (disregarding the bug you point to) ?
Comment 5 nucleo 2011-06-15 00:22:01 UTC
Yes, this patch fixes problem.
Maybe this feature should be experimental until will be working without  problems.

gtkperf will be most objective:

1. gtkperf tests with oxygen-gtk-1.1.0 without patch:

GtkPerf 0.40 - Starting testing: Wed Jun 15 01:12:06 2011

GtkEntry - time:  0,13
GtkComboBox - time:  6,36
GtkComboBoxEntry - time: 18,76
GtkSpinButton - time:  1,68
GtkProgressBar - time:  1,14
GtkToggleButton - time:  0,73
GtkCheckButton - time:  0,81
GtkRadioButton - time:  0,85
GtkTextView - Add text - time:  3,42
GtkTextView - Scroll - time:  6,30
GtkDrawingArea - Lines - time:  1,22
GtkDrawingArea - Circles - time:  1,43
GtkDrawingArea - Text - time:  0,47
GtkDrawingArea - Pixbufs - time:  1,03
Total time: 44,34

2. gtkperf tests with oxygen-gtk-1.1.0 with patch:

GtkPerf 0.40 - Starting testing: Wed Jun 15 01:15:01 2011

GtkEntry - time:  0,09
GtkComboBox - time:  4,71
GtkComboBoxEntry - time:  9,31
GtkSpinButton - time:  0,95
GtkProgressBar - time:  0,77
GtkToggleButton - time:  0,58
GtkCheckButton - time:  0,57
GtkRadioButton - time:  0,54
GtkTextView - Add text - time:  1,78
GtkTextView - Scroll - time:  3,56
GtkDrawingArea - Lines - time:  1,15
GtkDrawingArea - Circles - time:  1,53
GtkDrawingArea - Text - time:  0,39
GtkDrawingArea - Pixbufs - time:  1,24
Total time: 27,19

3. gtkperf tests with oxygen-gtk-1.0.5:

GtkPerf 0.40 - Starting testing: Wed Jun 15 01:16:17 2011

GtkEntry - time:  0,09
GtkComboBox - time:  4,31
GtkComboBoxEntry - time:  4,80
GtkSpinButton - time:  0,61
GtkProgressBar - time:  0,52
GtkToggleButton - time:  0,43
GtkCheckButton - time:  0,47
GtkRadioButton - time:  0,40
GtkTextView - Add text - time:  0,57
GtkTextView - Scroll - time:  1,17
GtkDrawingArea - Lines - time:  1,11
GtkDrawingArea - Circles - time:  1,39
GtkDrawingArea - Text - time:  0,41
GtkDrawingArea - Pixbufs - time:  0,85
Total time: 17,12

I also noticed scrolling performance degradation after updating from 1.0.5 to 1.1.0.
Comment 6 Hugo Pereira Da Costa 2011-06-15 00:44:55 UTC
Degradation with scrolling are unrelated to this bug and due to the inner shadows on lists, most likely. This feature should also explain the differences between test 2 and test 3 above. (animations are probably the other main source).

Now what do you learn from that ? That more complex (and better rendered) styles take longer than simple one ? I agree. In fact oxygen-gtk-1.0.0 is already the slowest gtk theme on the market (and oxygen-qt probably is too). If speed is the issue, users are still free to use simpler gtk styles. Right ? To me it makes perfect sense that the more feature you add the slower the code gets. (though we do try to minimize the effect). 

So this, at least, is definitly not a bug. Agreed ? Yes/No ? 

Concerning "Maybe this feature should be experimental until will be working without problems." Here also, trust me, after spending hours on it, there is *no other way* (this is a gtk2 limitation, which actually got fixed in gtk3). So we balanced the pros (better rendering), and cons (one extra resize when *some* dialogs pop up), and deemed it acceptable (and *not* experimental). Call it a design choice.

PS: you did not answer the second question asked in comment #4.
Comment 7 nucleo 2011-06-15 01:27:14 UTC
I am not designer so personally for me inconsistent implementation of groupboxes (in 1.1.0 with patch or in 1.0.5) looks good enough.
Maybe performance more important for me than consistence. It will be not very good if oxygen-gtk will implement exactly the same look as in oxygen-qt but we have to pay such price as low performance or resizing or other things.
Of course users can use other gtk styles (there are not much other styles makes gtk programs looking Qt-like), but maybe the main reasons why they are will not use gtk-qt-engine and use oxygen-gtk instead is no such bugs in oxygen-gtk  as gtk-qt-engine have, much better performance.
But only one groupboxes feature leads to significant (according to 1 and 2 tests) performance decrease and resize issue reported in this bug. If other features will be implemented with such price then oxygen-gtk may became not more preferable than gtk-qt-engine.
If resizing problem fixed in gtk3 why not leave implementation of Qt like groupboxes only in oxygen-gtk3?
Comment 8 Ruslan Kabatsayev 2011-06-15 07:07:06 UTC
Feck... all of the time i was thinking nucleo was talking about comboboxes...
Comment 9 Hugo Pereira Da Costa 2011-06-15 14:38:36 UTC
Git commit 1cec3605b5abadb5152d432f61d1896dc399ca7e by Hugo Pereira Da Costa.
Committed on 15/06/2011 at 12:03.
Pushed by hpereiradacosta into branch '1.1'.

added ENABLE_GROUPBOX_HACK flag to disable groupbox rendering.
CCBUG: 275665

M  +5    -0    CMakeLists.txt     
M  +9    -0    INSTALL     
M  +1    -0    config.h.cmake     
M  +6    -2    src/animations/oxygenanimations.cpp     

Comment 10 Ruslan Kabatsayev 2011-06-15 14:44:34 UTC
> I also noticed scrolling performance degradation after updating from 1.0.5 to

Inner shadows hack can also be disabled by ENABLE_INNER_SHADOWS_HACK=0. You'll then get that ugly shadows look from v1.0.5.
Comment 11 Hugo Pereira Da Costa 2011-06-15 15:14:07 UTC
Also, after investigating, the gtkperf deterioration between 1) and 2) is *not* due to the resize bug. It is due to the special background rendering for groupboxes, which is practically as complex as the "normal" window background and painted on top. Better rendering, lesser performance.

What hits us here is that all gtkperf windows are inside Groupboxes, so the background gets re-painted a lot of times.

Luckily enough, this is not representative of many gtk apps. (which shows some of the limitations).
Comment 12 nucleo 2011-06-15 15:45:37 UTC
-DENABLE_GROUPBOX_HACK=0 fixes wireshark capture window resizing.
Also I built oxygen-gtk-1.1.0 using -DENABLE_INNER_SHADOWS_HACK=0 and -DENABLE_COMBOBOX_LIST_RESIZE=0.

Performance now better with this flags but still slightly worse than with 1.0.5 (most notable in GtkTextView and GtkComboBoxEntry  tests).

GtkPerf 0.40 - Starting testing: Wed Jun 15 16:38:08 2011

GtkEntry - time:  0,07
GtkComboBox - time:  3,10
GtkComboBoxEntry - time:  9,81
GtkSpinButton - time:  1,13
GtkProgressBar - time:  0,61
GtkToggleButton - time:  0,53
GtkCheckButton - time:  0,47
GtkRadioButton - time:  0,48
GtkTextView - Add text - time:  4,11
GtkTextView - Scroll - time:  4,12
GtkDrawingArea - Lines - time:  0,96
GtkDrawingArea - Circles - time:  1,19
GtkDrawingArea - Text - time:  0,36
GtkDrawingArea - Pixbufs - time:  1,02
Total time: 27,98
Comment 13 Hugo Pereira Da Costa 2011-06-15 15:49:28 UTC
Remaining differences are likely due to animations.
(that you can disable via oxygen-settings). but again, I do not see the point.

Anyway. Closing, since the "guilty" feature can now be turned off (at compile time).
Comment 14 nucleo 2011-06-15 15:53:54 UTC
Maybe GROUPBOX feature should be disabled by default in oxygen-gtk and enabled in oxygen-gtk3 since real fix possible only in gtk3.
Comment 15 Hugo Pereira Da Costa 2011-06-15 15:59:20 UTC
I disagree, as mentionned before already: 

"So we balanced the pros (better rendering), and cons (one extra resize when *some* dialogs pop up), and deemed it acceptable".

Ruslan ?
Comment 16 Ruslan Kabatsayev 2011-06-15 16:02:10 UTC
I agree to Hugo.

If you really want this to be disabled by default, then there should be some poll to see what others think of this (maybe on kde-look.org).
Comment 17 Hugo Pereira Da Costa 2011-06-15 16:07:15 UTC
No, no. No poll. Open Source is no democracy (tm), and we (Ruslan and I) are entitled to decide. 

Now, if many people complain (since happy people usually don't manifest themselves) we "might" reconsider. (though the definition of "many" is left to our discression).