Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add freeze functionality #72

Closed
wants to merge 2 commits into from
Closed

Conversation

@Decodetalkers
Copy link
Collaborator

Decodetalkers commented Oct 27, 2023

Libwayshot also used in recording screen, it is not just used for screenshot. So when recording screen, it should not freeze itself,

Ok , I misunderstood this code. I think it will be fine

@@ -174,18 +167,19 @@ impl WayshotConnection {
cursor_overlay: i32,
output: &WlOutput,
fd: T,
capture_region: Option<CaptureRegion>,
) -> Result<FrameFormat> {
) -> Result<(FrameFormat, FrameGuard)> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Region is used in recording screen ,I do not think you should remove it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I'll keep support for requesting a screencopy for a specific region for the purposes of screen recording. I hadn't kept that in mind originally.

@Decodetalkers
Copy link
Collaborator

I think we should leave the exported functions have full features of wlr-screencopy, include user can pass region to capture an area. I think region , at least optional region is still needed to be a param

capture_region: CaptureRegion,
cursor_overlay: bool,
) -> Result<RgbaImage> {
self.screenshot_region_capturer(RegionCapturer::Region(capture_region), cursor_overlay)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so? RegionCapturer is a new enum to differentiate what we're capturing:

pub enum RegionCapturer {
    Outputs(Vec<OutputInfo>),
    Region(CaptureRegion),
    Freeze(Box<dyn Fn() -> Result<CaptureRegion>>),
}

Still need to do some documenting however to make this and the reasoning for it more clear!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a example above it ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will try to add an example of the freeze functionality. :)

@AndreasBackx
Copy link
Member Author

I think we should leave the exported functions have full features of wlr-screencopy, include user can pass region to capture an area. I think region , at least optional region is still needed to be a param

I have so far not kept backwards compatibility in mind. Though my plan was to get it to work and think of a good API. Then see what we can do to keep it backwards compatible for now. I think these changes teach us how we can still make a breaking API change later, but for now it's best not to break every revision regardless of whether or not we're still in 0.x and we don't promise backwards compatibility. :)

Thanks for the review, will make necessary changes.

@Decodetalkers
Copy link
Collaborator

Decodetalkers commented Nov 2, 2023

You have bring a file to commit

@Decodetalkers
Copy link
Collaborator

I think this pr is good.. but if there is some document is better, just no_run is ok

@Decodetalkers
Copy link
Collaborator

I do not think this pr is good enough... I have tried it.

First, I think freeze should be an option.
then, I have already use --slurp, but it still capture the whole screen and show it. I think if it is freeze, it should not need to be passed with slurp,

then the biggest problem is scale. when I use 2.0 scale or 1.5, the image cannot overfill my screen, it is terrible

@@ -12,10 +12,10 @@ pub fn set_flags() -> Command {
.help("Enable debug mode"),
)
.arg(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here should add on optional arg like freeze, because after freeze, we still need to do region select. so at first, we do not need to pass region to it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can make a new PR to add something like --region <GEOMETRY> which would replicate the old --slurp. It would lead to RegionCapturer.Region(LogicalRegion) to be used instead of RegionCapturer.Freeze(...) and thus do any selection up front. I'd want to do this in a new PR because any changes I make here now will result in me having to do the work again because #76 moves us to Clap derive. Would you want me to add it there perhaps?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's ok. Then solve the scale problem in this pr I think this pr is finished.

@Decodetalkers
Copy link
Collaborator

Decodetalkers commented Nov 10, 2023

And you should try to set one of the screen to scale 1.2 or 2, then you will find the problem, scale is the most difficult thing to handle, I think , like flameshot cannot handle it propertly.. This feature is like flameshot, if scale can be propertly handle , it will be a greate feature

@Decodetalkers
Copy link
Collaborator

and make freeze to an option , another thing is , take screenshots between screens. if we cannot handle scale property, then it will make problem when take screenshot near the side of two screens

Copy link
Collaborator

@Decodetalkers Decodetalkers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I think this pr still have some problems. thanks for your efforts again

@AndreasBackx
Copy link
Member Author

And you should try to set one of the screen to scale 1.2 or 2, then you will find the problem, scale is the most difficult thing to handle, I think , like flameshot cannot handle it propertly.. This feature is like flameshot, if scale can be propertly handle , it will be a greate feature

I have tried setting the scale to 1.2 which gives an error and something I am looking into. Could you explain the issue you see with a scale of 2 as I'm not immediately seeing an issue there? Could you provide the full command you use and the output you get vs what you expected?

@Decodetalkers
Copy link
Collaborator

PXL_20231121_013101904.jpg

Like this kind

@Decodetalkers
Copy link
Collaborator

And you should try to set one of the screen to scale 1.2 or 2, then you will find the problem, scale is the most difficult thing to handle, I think , like flameshot cannot handle it propertly.. This feature is like flameshot, if scale can be propertly handle , it will be a greate feature

I have tried setting the scale to 1.2 which gives an error and something I am looking into. Could you explain the issue you see with a scale of 2 as I'm not immediately seeing an issue there? Could you provide the full command you use and the output you get vs what you expected?

I have posted the image.. you should scale the captured to size of the screen

@AndreasBackx
Copy link
Member Author

I have posted the image.. you should scale the captured to size of the screen

Thank you! That makes it very clear. Will have a look at it.

output_info.wl_output.clone(),
);

layer_surface.set_exclusive_zone(-1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need the size from zxdg_output, not the size from frame_copy, the picture size by zwlr_copy is not always the size of the screen

width: _,
height: _,
} => {
tracing::debug!("Acking configure");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think buffer attach and commit should be here


surface.set_buffer_transform(output_info.transform);
surface.set_buffer_scale(output_info.scale);
surface.attach(Some(&frame_guard.buffer), 0, 0);
Copy link
Collaborator

@Decodetalkers Decodetalkers Dec 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

before attach, you need to clone the buffer, and resize its size to the size of zwloutput, reasion is the same

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants