 |
Looks good. If anyone finds a problem, open a new BT. |
|
|
@Olaf Later today or tomorrow, a fix will be checked into GIT to fix the bug you found in 3) of Note 2312: Appearance, Color: Composer GB Color (view scaled). I forgot to get this fixed (as I forget to do a lot!) |
|
|
@igorB " Is it better to change the value to 1.0 or can I leave the default value (0.0)?" Leaving it at 0.0 is what most people will do and is probably preferable so that if you move to a different monitor with different dimensions/resolution, it will automatically probe. |
|
|
@IgorB Thanks for testing. Yes, I have gone crazy resizing some plugin windows, now that I know how!. I will fix the one you found. I had not tested Format RGB. |
 |
GG/Phyllis, thanks for the Ub16-20191025 build. I tested it quickly, here and there, after deleting the “.bcast5” folder. I noticed that if I don’t change the Layout_Scale value from 0.0. to 1.0, in Preferences, it always works correctly on my Notebook screen (1280x800). Is it better to change the value to 1.0 or can I leave the default value (0.0)? I see that You (GG & Phyllis) are resizing the window of many plugins but take a look YUV411 plugin, please: the red text is on the button. I don’t know if there are other plugins with hidden text that is shown only in specific circumstances.
YUV411-plugin_resize1.png (21,578 bytes) |
|
|
All: 1) There is now a warning message if a user clicks OK in Preferences after changing Layout Scale, Theme, or Plugin Icons (and maybe other occasions) since there will be potential impact IF there is a running render or record or there will be a Restart. It reports Busy: render in progress. Are you sure? You can click Yes or No. Thanks to Olaf for this improvement suggestion. Checkin to GIT included more tweaks to window sizes of some plugins and scaling edge cases we found. There is a new Ubuntu16 version and Mint18 just to use to see if any issue pops up. https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz For fun, we tried out Olaf's suggestion but on Fedora a ; (semi-colon) means new line so only ended up with the last statement in effect: $ LANGUAGE=C;BC_SCALE=28.9;BC_ICON_SCALE=-0.4;BC_FONT_SCALE=1.0 cin & Instead, we used: $ LANGUAGE=C BC_SCALE=28.9 BC_ICON_SCALE=0.4 BC_FONT_SCALE=1.0 ./cin from the cin binary directory location. It worked, but sure is weird looking. |
 |
Optically everything is so far ok. 1) Settings->Preferences, Appearance: application restart. The warning hint is missing here. I say it now in all clarity on the basis of a no example. If the user renders his project and after two or three hours wants to check again which settings he has used for rendering, then he cannot do this because the "Render" dialog is locked altogether. Instead, he gets a message in a separate message window that rendering is already in progress. Not the "do it" button of the render dialog is locked, but the render dialog is completely suppressed. Knowing about this child-proof lock is important for what comes next. Now the user has time to make friends with the program. He looks at Preferences, Appearance and changes the layout. He doesn't get any helpful hints, he presses Apply and nothing happens, so at some point he'll push bored ok. And now something completely unexpected happens, the program quits without asking (!) and aborts the render process (!), which has already loaded all CPU's for full three and a half hours. - A perfectly set trap for new users. 2) As a professional command line gymnast with knowledge in DTP I would like to point out again that the size of the pixels of the monitor (DPI) is decisive. A 4k monitor (3840 x 2160 pixels) can also have a diagonal of 82 inches (207 cm) and more. HiDPI: High Dots Per Inch. Check that out, you'll like it (if something goes wrong, hold down the Alt+SysRq key combination and press the keys r, e, i, s, u, b one after the other): $ LANGUAGE=C;BC_SCALE=28.9;BC_ICON_SCALE=-0.4;BC_FONT_SCALE=1.0 cin & |
|
|
@All: latest checkin today includes Preferences scale settings which is saved across sessions. However, for ease of use in case the user makes a mistake in setting this, the environment variable, BC_SCALE, will take precedence. I think this method solves potential confusion. Here how it works: 1) A new user or someone who has never set the Settings->Preferences, Appearance tab, Layout section, "Layout Scale" text box with tumbler, will have the LAYOUT_SCALE set automatically at 0.0. This means an automatic probe of the biggest monitor is used as a setting. The big advantage of this is that "new users" with a 4K monitor will not immediately be discouraged on too small text/icons. 2) Current users who do not like this automatic scaling, should set the "Layout Scale" to 1.0 in Settings. This will avoid the smaller characters that might be a result of the probe of a non-1080p monitor. 3) Oops, I accidentally set "LAYOUT_SCALE" to 112.6. Use BC_SCALE=1.0 {your cin path}/bin/cin and then fix the Preference. Or you can always manually edit $HOME/.bcast5/Cinelerra_rc, the LAYOUT_SCALE parameter value. Also, other scaling cleanup in the GIT checkin and a couple of fixes - but nothing significant enough to create new builds unless someone requests one -- no problem. |
|
|
@Olaf "to use icons with a high resolution" is most likely possible. What GG thinks will work is the following: 1) cd theme_cakewalk/data, run allsvgstopngs.sh, but add a -d 200 to the inkscape command line. 2) rebuild cakewalk 3) cd cinelerra, set your scaling to what you want, for example: BC_SCALE=2.0 BC_ICON_SCALE=0.8 ./cin This may be possible to do in the theme initializer. 4) now your icons will look really good, but to make it work properly, you will have to convert every icon in the program to the 200 dpi scale or parameterize every icon, or similar. Attached is an example. x.png (423,597 bytes) |
 |
The 4k screen in the middle (when acquired...) would display the composer, most often with all the composer's frame (frame, icons buttons) and sometimes in full-screen mode where only the image content is maximized. |
|
|
@Pierre: Hmmmm, there is currently no way to handle that. There is only one scale value so the automatic probing would set the scale to the 4K monitor and all 3 monitors would use that. But with the GIT mod GG will checkin (probably later today), you can set a preference to override the probing with a Scale of 1 to look the best on the 2 side 1080p monitors since the 4K monitor in the middle could be used in fullscreen mode for the Composer. |
|
|
I have no way to test this right now (since I only have 1080p displays), but I wonder what will happen if I replace one of my displays (the one occupied by the composer) with a 4k display? I would then find myself in multi-screen mode, with a 4k screen for the composer in the middle and 1080p screens on each side displaying the other Cinelerra-GG windows. Would CinGG's display be individually adapted to the resolution of each screen in this multi-screen layout with different resolution screens? Pierre |
|
|
Thanks for feedback from Andrew, Andrea, IgorB, Pierre and Olaf on this subject. It has proven quite helpful. We are working on small cleanup to include as Andrea and Olaf suggested, a Preference. In particular a way to accomplish what Olaf suggested in 1) and 2) in the last note. I do not know the details of the "fix" yet. The automatic probe scaling as Olaf mentioned in 1) is important so that as Andrea mentioned, a new user with a 4K monitor is not immediately discouraged when he/she can not "see" the text characters/icons because they are way too small. Meanwhile you power users can always find a way to adjust !! I am still checking on 3) and the last paragraph in Olaf's note. My current understanding is that all icons will have to be created at a higher resolution and I will find out whether or not they will show that way. P.S. to me the 200 DPI graphics look pretty good. Also, as part of the cleanup, as Andrea mentioned, some of the plugin windows are not sized right -- and this is true before scaling was added - I am fixing a bunch of them. |
|
|
Guys, I finally found the time to set up a function key: +1 I ♥ it! Small joke, supplementing the past press comments my 2¢. 1) My monitor has a resolution of 2560x1440 pixels at 108 DPI and I am very happy with the unscaled display. Up to 108 DPI there is no reason for automatic BC_SCALE>=1 and should be left to the user. With my monitor I am now forced to specify BC_SCALE=1 or write a script. Which brings me to the next point. 2) BC_SCALE should be adjustable via settings. Proposal for the description under menu item Appearance, Layout: GUI and Font scaling (Adjusting the scale requires an application restart to re-layout.) 3) I noticed a little bug: Appearance, Color: Composer GB Color (view scaled) For some reason, I assumed that the high resolution themes would be created extra and then used instead of the usual 96 DPI export. However, the icon theme is simply scaled up to show artifacts. But as long as only users with low resolution monitors will use this feature, the artifacts will only be taken as blurred images. It is not possible to use icons with a high resolution at the moment, for entertainment, I've included a screenshot showing CGG with 200 DPI graphics. BC_SCALE-Auto_200DPI.webp (112,512 bytes) |
|
|
Okay, I installed the test version for Mint18. I don't know if I'll really see any differences, I don't have any 4k screens; all my screens are 1080p (even if I use three side by side in multi-screen mode). I use the Neophyte theme. If I observe a problem, I will report it. |
|
|
@peregrine OK, we have a solution and if anyone could test, we would really appreciate that. You will have to download the appropriate distro static tar to test. There is currently a Ubuntu16, Mint18, and Ubuntu18 available but we will build any other distro static tar for willing testers -- just let us know which distro. The available static tars can be downloaded by going to: https://www.cinelerra-gg.org/downloads/#documentation and clicking on the "file storage" icon. To test, you will have to use this line from a window: BC_SCALE=2.0 {your cinelerra path}/bin/cin Testing involves just "using" it. The 15, 500 insertion and deletion lines are only supposed to impact the size of windows, text, spacing, and icons. For a little more information you can refer to: https://www.mail-archive.com/[email protected]/msg00674.html |
|
|
> "And how does that affect the themes, the graphics are all static after all." After examination I come to the result: From the themes Neopyte, Cakewalk and Unflat you can immediately create themes for DCI 4K/UHD 4K. This would give CGG three real 4K themes. Whether slight adjustments will be necessary will be seen after the rebuilding of the framework. |
|
|
> Phyllis: "Just an update prompted by a forum item stating that this is a timely, desirable and necessary improvement. WTF? Boredom? And how does that affect the themes, the graphics are all static after all. |
 |
Very interesting; there is also a fork di Xephir that introduces OpenGL in hardware. https://github.com/fenghaitao/xserver-with-gl-accelerated-xephyr |
|
|
Xephyr might be an interesting approach - thanks for testing this out. |
 |
Ah, it works, as in sense I can see same wrong layout in Project Format if I set both BC_ICON_SCALE=2 and BC_FONT_SCALE=2. So, i think at least GG can try Xephyr command for emulating HiDPI screen .. but this require a lot of mousing around (and use of alt + mouse drag) |
|
|
I tried to 'emulate' HiDPI screen via Xephyr, but for me (E16 window manager + CinGG) at least project settings dialog was normal?! Try Xephyr -screen 3200x2600 -dpi 450 :1 DISPLAY=:1 starte16 (or startfluxbox, or something of this effect) Then from big Xephyr window launch cin. May be you can even keep cin-windows inside this emulated X server (on real HiDPI screen) with low dpi, and use compositor at least on real screen with HiDPI ? |
|
|
Just an update prompted by a forum item stating that this is a timely, desirable and necessary improvement. Question was without actually having a 4k monitor to work on "can't you change the program and have users test it and see if it works?" From our experience, this potentially takes at least 1 dedicated tester with at least 1 month of time. A case in point was the ShuttlePro where Pierre had this extremely devoted time to assist, we also had the hardware, and it definitely took more than a month to get it properly implemented. Hoping a volunteer programmer shows up! |
 |
Upload two sample screen shots from Cin GUI on XPS 13 (9370) with 3840x2160 UHD HiDPI display. To be properly readable the following environment variables are set export BC_ICON_SCALE=2 export BC_FONT_SCALE=2
Set_Format_HiDPI.png (84,610 bytes)
Font_type_HiDPI.png (89,095 bytes) |
|
|
Level 2 or 3 HELP needed --------------------------------- Good idea to put this on the future roadmap. A user did notify us in June about this and at that time we responded as follows. "474 is the number of references in cin5/guicast code that would have to have X and Y scaled for hidpi. This is a relatively easy task, but in most cases this is simple scaling (which is not the same as re-packing) the widgets in the panel geometry will produce a kind of "grainy" result in cursor positions. Re-packing would require reworking the layout in all of the guis and plugins. Not impossible, but no small task. However, the technical programming is not the problem, whereas creation of a patch and testing would obviously require a monitor and graphics card that is capable of running in HiDPI mode. And we don't have one of these." A C programmer with an HiDPI monitor could handle this at a Level 2 or 3 (rating system of Level 1 being easiest and level 5 being hardest). We would get someone started and help all along the way. Meanwhile, users who are lucky enough to have an HiDPI computer setup can at least use the following to better see and these can be added to your .profile file: export BC_ICON_SCALE=2 export BC_FONT_SCALE=2 |
- Anonymous
