Screenshot does not obey its mouse pointer option

[Adek336]

Screenshot always captures the mouse and he doesn't wait the time you set in his preferences. He also always takes photo of whole screen, even when "take active window" is selected.

[julun]

This seems to be 3 different issues here:

• Screenshot always captures the cursor - introduced with change hrev24346 (only visible with vesa in that change(use Magnify in 24345 and 24346) not with real driver like vmware - In HEAD also visible with real driver!(probably because they use now double buffering as well))
  
  
• Screenshot takes always the full screen - could not reproduce with HEAD, please give more info
  
  
• Does not respect the timeout - could not reproduce with HEAD, please give more info
  

Best regards,
Karsten

[stippi]

The fullscreen problem could be because it thinks the wrong window has focus (Tracker's desktop window). At least I have observed some flakieness with regards to picking the right focus window when I checked out the app. I was using focus follows mouse.

As for the cursor, I think I know what the problem is...

[julun]

<snip> The fullscreen problem could be because it thinks the wrong window has focus (Tracker's desktop window). At least I have observed some flakiness with regards to picking the right focus window when I checked out the app. I was using focus follows mouse. </snip>

I wonder what one would expect while using 'focus follows mouse', it takes a screenshot of the 'active' window?

[Adek336]

[quote]- Screenshot takes always the full screen - could not reproduce with HEAD, please give more info

• Does not respect the timeout - could not reproduce with HEAD, please give more infoquote

Quite interestingly, I was pressing the "Save" button thinking it was the "Take snapshot" button :-) So after all, these two problems didn't happen.

[humdinger]

From Adek's last comment, I understand it's only the mouse pointer option, that's not respected. I can confirm this using the nvidia driver in hrev34203.
Changed ticket title accordingly and stroke through wrong part of the original description.

[Wim]

I have created a simple patch that solves this bug, but since it doesn't deal with the root problem it could be classified as an ugly hack. I will submit the patch anyway, and leave it up to whoever is in charge to decide whether or not to apply it. I won't be offended if it isn't used :)

[axeld]

It's actually not a big hack, at least I don't see a better way of doing this easily.

However, there is one problem, as it does not take the current cursor status into account; if it's currently not visible, it could be for and after the screenshot.

[Wim]

Replying to axeld:

However, there is one problem, as it does not take the current cursor status into account; if it's currently not visible, it could be for and after the screenshot.

OK, I will fix that.

I have one question: since the drawCursor parameter of the DrawingEngine::ReadBitmap() function does not seem to do anything at the moment, is it better to remove it from the function call, or do you prefer to leave it like it is so the API doesn't change?

[Wim]

Oh, yeah, I forgot: what about ticket #2997, which basically describes the same problem.

[Wim]

Patch that hides the cursor before calling DrawingEngine::ReadBitmap()

[Wim]

Updated the patch so it takes the current cursor status into account.

[axeld]

Thanks. Sorry, though, my first evaluation was wrong - I just looked into DrawingEngine::ReadBitmap(), and it already contains code that looks like it should work. In other words, one should rather fix what's wrong there than to work around it like this.

[axeld]

Since Stephan wrote this code, maybe he has some idea.

[stippi]

Yes, I've already "fixed" this code a long time ago, but there was one remaining issue, which was really strange and I couldn't resolve it, and I never commited the code. I don't remember which computer I made the changes on, but I can find out as soon as next Friday... unless it's lost. IIRC, the problem with the code is that it inserts the mouse pointer in the wrong buffer, but maybe there was more. When the app_server works in double buffered mode, the back buffer should not actually contain any mouse pointer, but one still wants to use the front buffer to capture BDirectWindows.

[Wim]

Fixed in hrev37017.