D25427: [Wayland] Allow to take full resolution screenshot when scaling is used

Méven Car noreply at phabricator.kde.org
Wed Apr 15 15:30:37 BST 2020


meven added a comment.


  In D25427#648962 <https://phabricator.kde.org/D25427#648962>, @davidedmundson wrote:
  
  > > For single screen, there is nothing to argue, I believe, the patch solves the issue : do not downscale.
  >
  > Ack. The changes to blitScreenshot are all good to go. +2 on that bit.
  >
  > > pixel precision is needed for use cases such as debugging, "real" pixel screenshot, screenshot apps such as spectacle
  >
  > The spectacle part is where I'm a bit lost. Could be that you have additional plans there.
  >
  > Spectacle (currently) shows one mega-window spanning across all screens showing one image for its crop/select area function. Because it's all one window all contents need to be at the same scale as that wl_surface only has 1 scale.
  >
  > I don't see how Spectacle could do anything useful with this unless it got the image, then mapped it back to the screen geometry and split it up again into individual pieces.
  >  At that point would it work better for spectacle to call DBus  screenshotScreen(0); screenshotScreen(1); and getting native images back directly pre-split?
  
  
  It could add latency to screens between screenshots, and it would suppose having some prior authorization to take screenshots.
  
  A single call would be better I think.
  Returning a list of images perhaps instead of all of them assembled.
  
  > 
  > 
  >> If that sound reasonable I will add a screenshotFullscreenScaled or a boolean scaled argument to screenshotFullscreen, to the screenshotEffect.
  > 
  > Remember I loathe the term "scaled", but in principle I would be ok with that if we can work out how spectacle would use this.
  
  I wonder what would a better word than scaled.
  In spectacle, you would have another screenshot type "Multi Screen Linearly scaled".
  
  Also assembling the images will be tricky, given we won't have any available geometry for this case.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D25427

To: meven, davidedmundson, #kwin
Cc: nicolasfella, zzag, davidre, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200415/0d92a8c0/attachment.html>


More information about the kwin mailing list