 |
All of the planned changes have been made. The only possibly outstanding issue is whether to center a zoomed in image in the compositor centered or with the same left and top margins as the un-zoomed image. This is a matter of preference and if multiple users believe it should be centered AND it can be easily programmed that way, then it can possibly be done. See BT 0000358 for the problem on some Operating Systems with switching workspaces when in full screen mode that I can not generate on Fedora. |
|
|
@Olaf: if you had a chance to build and test the compositor zoom, exactly what would you still like to work differently? only the centering? |
 |
Thanks Phyllis for the Ubuntu 16 build. Unfortunately, yesterday, "Charlie" (my old notebook) is dead. I tried to fix it. I disassembled it; clean and put new thermal paste on CPU, GPU; checked the connectors. Re-assembled but Charlie doesn't work anymore (sigh-sigh). I think Mother Board is burned (It restart every 2 seconds, and I can not enter in BIOS). Now I am writing to you with my mule desktop (monocore CPU). I am "out of the game" for a while. Sorry. And I'm sorry for Out Of Topic. I add a photo of Charlie. (No flowers, please) :-/
Charlie-Disassembled.jpg (163,447 bytes) |
 |
What I like about Olive is that the developers do video editing themselves, so they develop the editing program from the user's perspective. |
 |
I have validated that the zoom behaves well here as you describe it. As for the sound compression plugins, I tried them. They are visually impressive and seem to work, but I'm not a sound expert; I rarely use compression on my soundtracks, usually I just filter certain frequency ranges and adjust the gain. |
|
|
First, a summary of the changes just checked into GIT for zoom: - If Auto set in the compositor, then fullscreen works as before and so just puts the image in the full screen as currently portrayed. Probably this is what most users are using anyway. - if other magnification, then when switching to full screen mode, the image is kept at that magnification and more image is displayed in full screen if it fits. But, AND THIS IS IMPORTANT, the top and left margins WILL BE MAINTAINED as portrayed in the compositor because that is what seems to work best and provides more flexibility for moving around. In other words, the video area is set to the upper left quarter. - when switching back in the case of other magnification, you will be exactly where you were in the compositor before going to full screen mode. This makes it so you can scroll and zoom in full screen mode, but get you back to where you were before in non-fullscreen mode. There are static tars for Mint 18 and Ubuntu 16 if anyone wants to test out some of the changes already in this month's checkins to include the new Foreground, Alpha, and Compressor multi plugins at: 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 Second, some commentary on modifications made and other notes: - As suggested, I did look at how Gimp does zoom and I thought that centering was undesirable. I also noticed when going fullscreen that if more of the image could be displayed, it would be. So that is what I requested from the developer. Some changes are often a compromise with requests, what can be done easily, and what I like. If there is an exact request for something different, it will be considered. Olaf quote: "In addition, the old fullscreen-in-the-root-window bug is back. After switching to another workspace and back again, the so called Compositor writes the full view into the root window of all workspaces." Give me something to work with here -- exactly when did this bug come back time wise? It worked OK in November? and now it does not? Also, I liked the use of the terminology "the so called Compositor" -- I laughed when I read that. MatN quote: "I think this ought to be a separate issue, because it is unrelated to the zoom issue." I agree and will open a new BT on this. |
|
|
From Note 2538: "(Btw, black is so yesterday ;-)" Changes to Zoom are still planned, but I just wanted to show what the 7.2 HV compositor background default is now -- hint, it is NOT black !!
compositor_background.png (21,500 bytes) |
|
|
The arguments were declaimed, whether and how they will be taken up I leave to the discretion. |
 |
Ah, now I see what you mean. IMHO it is not a bug, because it works as designed. It could definitely be better, though. When I configure for 2 workspaces (Mint 19.2 XFCE), I can switch back and forth using Ctrl-F1 and Ctrl-F2. Suppose I use cin-gg in workspace 1, go full screen in the compositor, then indeed Ctrl-F2 doesn't react. I can either wait a long time (a minute or so, then it seems to go back), or use the mouse left button to go out of full screen mode. Then I am immediately in workspace 2, so somehow the Ctrl-F2 made it through. I hope GG can see a nicer way of implementing this. I think this ought to be a seperate issue, because it is unrelated to the zoom issue. |
|
|
> MatN: "I presume he means desktop workspaces, which on my XFCE desktop I switch to using Ctrl-F1 through Ctrl-F4. If I am full screen, it doesn't seem to do anything." > PhyllisSmith: "Full screen mode is an "unmanaged window" and as such does not obey window manager orders." I'm just saying it's a bug in CGG. Imagine for a moment the phone is ringing and you have to go to your customer data on the other workspace, but the compositor is stuck in full screen mode for some reason. How do you want to get out of this number? The compositor is only allowed to occupy one workspace, but not all. For this I mention the media players MPV and VLC, whose behaviour in full screen mode supports my argument. By the way, Cinelerra's windows all have the same WM_CLASS. This shows that Cinelerra is not willing to work with window managers at all. |
|
|
From note 2518 -- "fullscreen-in-the-root-window bug is back. After switching to another workspace and back again, the so called Compositor writes the full view into the root window of all workspaces." Full screen mode is an "unmanaged window" and as such does not obey window manager orders. A lot of the popup windows in Cinelerra are also unmanaged windows. I was able to display the example.webp file to view what Olaf is talking about but it is not possible to switch workspaces in Fedora from an unmanaged workspace. That is, as MatN stated (note 2519) when you are in Full Screen mode, he could not even change workspaces and neither could I (I actually logged in as an ordinary user rather than my usual root and can confirm). I am outlining potential changes to Zoom in the compositor to see if they can be implemented. For example, do not ignore fixed magnification when switch to full screen mode UNLESS in Auto mode or Protect Video from changes mode. And as MatN stated - "Basically a larger compositor window". |
|
|
And no, it's not possible for the Window Manger to impose this task. Firstly, the full screen cannot be guaranteed, because Window Manger can reject parts of it and thus an enlargement with "crooked" dimensions takes place and secondly, this is the task of the program to present a representation optimized in this view. |
|
|
MatN: "he wants the full screen display use the same zoom as currently used in the compositor. Basically a larger compositor window." Exactly. Only it is and remains the compositor, only that, as I wrote before, a part of the controls is no longer accessible. |
|
|
> 0000344:0002533 to 1) Exactly. (Btw, black is so yesterday ;-) to 2) No, what makes you think so? Think briefly about it. Because we have a video editor and not a video player (even if this option is available). Just take a look at how other image editing programs (Gimp, Darktable …) switch to full screen mode. If you take it exactly, even the control elements shouldn't be faded out or only requested on explicit. |
|
|
Correction, I mean Olaf, not Pierre. Excuses. |
|
|
If I understand Pierre correctly, when he switches from compositor to full-screen, he wants the full screen display use the same zoom as currently used in the compositor. Basically a larger compositor window. I think that most people want full screen to show the full picture. But maybe his need can be accommodated by adding "shift-f" to the compositor's shortcuts, which means show compositor full screen with current magnification? For working with masks, it is very handy to have the compositor not set to auto; when you zoom in it is easier. But then still I'd prefer full screen to mean full picture. However, I'm an occasional user. What do other heavy users think? |
|
|
I agree with MatN #0002525 For me the word “Full Screen” means to fill the screen completely, and it may be up-scaled or down-scaled due to your monitor resolution, but with the correct aspect ratio (16:9, 4:3, 21:10,…). Eventually I can understand another option as “View 1:1” where the screen shows only the contain of the Compositor in the middle of the screen. So,... 1) if my format project is HD (1280x720) and my screen is FHD (1920x1080), I will see the picture in the middle of the screen with an empty background color (black?) all around. 2) if my format project is UHD (4k, 8k,...) and my screen is FHD (1920x1080), I will see the picture in the middle of the screen but zoomed. Another way for “Full Screen” option, could be,… to fill the screen with the picture if the format project is greater than screen resolution (as it is now); if the format project is smaller than the screen resolution the picture is displayed with size 1:1, in the middle of the screen. (cinelerra-5.1-ub16.04-20191130.x86_64-static) |
|
|
It's not that difficult. Videos and screenshots show that the majority of users have set their compositor to "automatic" most of the time. When switching to full-screen mode in automatic mode, the monitor shows a full screen display. So for the majority, nothing changes. On the other hand, there is no argument that explains why a fixed magnification is ignored when switching to full screen. If the user wants a detailed view of 300 percent, then his decision has to be respected, regardless of the size of the compositor, with or without window decoration. And it is also not a solution to force the user to manually search for an already set magnification again with the mouse or plus and minus keys after switching to the full screen. The correct way is to search for another magnification from the set and retained one! The compositor doesn't know any better than the user, he can't and shouldn't ignore the requirements of the user, no matter how crazy and absurd they may look for third parties. The compositor has to be reworked anyway, because the switching doesn't work clean. |
|
|
It's curious how difficult this discussion is to follow... it seems that there is no consensus on the objective sought by the full screen mode. For me, the full screen mode is used to evaluate the impact of the image delimited by the composer's frame (like the viewer) but once reported to the total size of my monitor (whatever its resolution) and without the CinGG interface. As if I were watching the final rendering of what I did, on the screen chosen for the presentation. If manipulations have been made on the composer's visible content, then this visible content (within the composer's framework) should be the same as that reported in full screen mode. |
|
|
@Olaf -- I am missing it too !! When going full screen in the previous versions, the image on the display was the exact same size as in the compositor. That is, if the compositor was about 1/4 the size of the entire monitor, let's say in 50% mode on a 1080x1920 display the image is about 2 inches tall by 4 inches wide. When the user went to Full Screen mode, the image was still 2 inches x 4 inches. That did not make any sense to me. |
|
|
I'm not sure I follow you here. In my view, the "full screen" should display the whole picture, scaled as appropriate, not the compositor's windows content. E.g. a HD picture on a 1920x1080 screen should map pixel-perfect even if the compositor is in a 300% zoom, on a UHD monitor should be scaled up, and an UHD picture on a 1280x1024 screen must be scaled down. In both cases I expect "full screen" to show the whole picture. If a bigger compositor view is desired, increase the compositor window (save a separate layout if needed). Note that is if the compositor "zoom view" is on, it is very easy to zoom in and out the the mouse scroll wheel, in both normal and full-screen mode. I find it especially convenient that when scrolling with the wheel, the center of the zoom is where the mouse pointer is. I noted yesterday that Adobe PP has no facility to scroll using the mouse wheel in full screen mode. |
|
|
The task was simple: maintain the magnification set by the user in each view. Example: A FullHD* must also be displayed in full view with 100 percent if 100 percent is set. This serves to evaluate the video in the size chosen by the user without disturbing accessories such as window frames and colorful background images. There is a difference in perception when a FullHD is scaled up to 2k, 4k or 8k or something else depending on the monitor, it is also a generated image. *If in your test environment the used monitor can display FullHD at maximum in the resolution, a smaller size like 50 percent must be used for testing. This is the only way to check whether the magnification is maintained in the full view or whether the automatic scaling is used. |
|
|
I can confirm that with release 2019-11 my not-full-screen-used bug has been fixed. Just before the upgrade from 2019-10, I confirmed that is was still present there. @Phyllis, I followed the same steps as in your video, except that I used the 'f' key to switch to and from full screen mode. In full screen mode the compositor picture occupied the upper left corner of the screen like in Olaf´s note 2516. Have you done the test using the vanilla 2019-10 release? Anyway, it is fixed now for me. I don't know how to reproduce Olaf´s fullscreen-in-the-root-window bug from note 2518. I presume he means desktop workspaces, which on my XFCE desktop I switch to using Ctrl-F1 through Ctrl-F4. If I am full screen, it doesn't seem to do anything. If I am not full screen, switching back and forth doesn't not cause any noticable problems. By the way, I could not display the .webp file in note 2518, the link is https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=378&type=bug , but I get the "MyView" screen instead. The .png picture in note 2516 works fine, and my Forefox should support .webp pictures. |
|
|
When I wrote it would work so far, it referred to the git version of November 30th. In addition, the old fullscreen-in-the-root-window bug is back. After switching to another workspace and back again, the so called Compositor writes the full view into the root window of all workspaces. CGG_fullscreen-in-the-root-window-bug.webp (56,012 bytes) |
|
|
Okay, works so far. However, it would be nicer if the video area were displayed in the center of the fullscreen view. Except in the "Auto" setting, the video area is set to the upper left quarter.
CGG_Fs_HD-x1.png (2,097 bytes) |
|
|
Changed the code so that now it remembers the magnification setting in the compositor before going fullscreen so that when leave fullscreen, you are back to the previous size. We had avoided doing this previously simply because that the parameter value was not readily available. @MatN: I am not able to create the issue you see so I must be misunderstanding something. In this quick video, I have a 1920x1080 video, set the compositor to 100%, and since my laptop's screen is 1920x1080, I correctly see the center portion of the image in the compositor. When I go fullscreen I see the entire image. Demo is at: https://streamable.com/xv77q |
|
|
What is also strange, if I edit an HD video, set the compositor magnification to 100% (about half the actual screen width), the put the compositor full screen, I don't get the full HD picture. This is on a 1920x1200 screen, it would fit without scaling. 100% will exactly fill the width of the screen, so I think showing only part of what was visible in the smaller compositor is incorrect. If magnification is set to auto, it works fine. |
- Anonymous
