[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request: Implement color correction (per output)
From: Thomas_Lübking <thomas.luebking () web ! de>
Date: 2012-11-09 18:00:53
Message-ID: 20121109180053.26386.88401 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Aug. 23, 2012, 9:35 p.m., Christoph Feck wrote:
> > kwin/libkwineffects/kwinglcolorcorrection.h, line 27
> > <http://git.reviewboard.kde.org/r/106141/diff/1/?file=80371#file80371line27>
> >
> > Unless you really need a specific order, use QHash instead of QMap for mapping.
> >
> > All operations of QHash are near O(n), while QMap has O(log n).
> >
> > (On a second look, you probably DO use the ordering, so that comment may be void)
>
> Christoph Feck wrote:
> Of course, I meant QHash has O(1), not O(n) ... otherwise it wouldn't be faster. \
> Sorry for the confusion.
> Thomas Lübking wrote:
> Just FTR: it's not that simple.
> QHash has a static overhead what makes QMap accesses cheaper for very few elements.
> Also insertion into QHash is more expensive.
>
> If one only required a combined list one wants QList<QPair<>> but that's not the \
> case here (while i'm not sure the map/hash is actually used at all)
> While at it:
> @Casian
> did you mean to use QMap<Window, QList<QRect> > instead QMultiMap?
>
> Casian Andrei wrote:
> This code is executed very rarely, so it wouldn't matter even if it would be \
> O(n^3). Also, n should be quite small. I will keep in mind to use QHash in the \
> future when it's advantages come into play.
> I chose QMultiMap instead of QMap<Window, QList<QRect> > because, well, it looks \
> shorter and fancier :) . I thought that if QMultiMap exists, perhaps it has some \
> useful convenience methods for this kind of use.
> The purpose of this map is to be able to get all the regions for a specific window \
> right away - when drawing the window. The idea is that complexity and ugliness \
> (like this multimap) should be set up once when the region profiles are fetched, \
> and it should make life as easy as possible for the compositor when drawing the \
> windows.
> If there is a reason for using QMap<Window, QList<QRect> >, I will modify :)
Sorry, I just notice i forgot to publish this reply.
@Casian
please check whether this item is actually still up-to-date, I'll have a second look \
then.
-----
> The purpose of this map is to be able to get all the regions for a specific window \
> right away
-> QMap<Window, QRegion>?
multimaps require repetitive data lookup (ie. you need to seach for all rect entries)
Depending on how often this is called and how complex your window regions become (eg. \
some applications used to shape drag and drop text windows...) it can have quite some \
performance impact.
> On Aug. 23, 2012, 9:35 p.m., Christoph Feck wrote:
> > kwin/libkwineffects/kwinglcolorcorrection_p.h, line 81
> > <http://git.reviewboard.kde.org/r/106141/diff/1/?file=80373#file80373line81>
> >
> > Usually, private d_ptr classes should not be virtual. If there is a reason, \
> > please explain.
>
> Casian Andrei wrote:
> I lack experience on this...
> Is this still an issue? Will fix right away if so.
The question behind this is why the d pointer is a QObject. If it's just for those \
two slots, consider moving them up..
There's btw. no reason to repeat the virtual keyword in a derived class. (and \
actually i thing the coding style says "don't" - but i'm no way known an expert in \
that regard ;-)
You cannot withdraw virtuality and *never* should add it (ie. make a non virtual \
function virtual in a derived class - has usually little point either and can cause \
some headaches)
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106141/#review17924
-----------------------------------------------------------
On Oct. 27, 2012, 9:56 a.m., Casian Andrei wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106141/
> -----------------------------------------------------------
>
> (Updated Oct. 27, 2012, 9:56 a.m.)
>
>
> Review request for kwin, Thomas Lübking and Martin Gräßlin.
>
>
> Description
> -------
>
> These are the results of my GSoC project, for KWin.
>
> This color correction needs KolorManager installed, master branch. That one needs \
> Oyranos and additional color management dependencies. \
> git://anongit.kde.org/kolor-manager.git http://www.oyranos.org/downloads
> If it's not installed, the ColorCorrection class should fail without causing any \
> issues to the user (that's if it's enabled from the KCM). Probably a notification \
> could be appropriate in that case? "Failed to initialize CC because cannot contact \
> Kolor-Server KDED..." something like that?
> Change summary:
> --
> Add an option to kcmcompositing in the 'Advanced' tab, to enable or disable color \
> correction. It is specified that it's experimental and it needs Kolor Manager. This \
> implies some small changes to options.h and cpp.
> Scene::finalPaintWindow code is moved into SceneOpenGL::performPaint.
> SceneOpenGL has the declarations of some methods changed to include the screen \
> number - those could be changed to pass around PaintData's probably. SceneOpenGL's \
> newly implemented finalDrawWindow splits the rendering if color correction is \
> enabled and there are multiple screens. Before painting for a particular screen, \
> ColorCorrection::setupForOutput should be called.
> There was a problem with the blending function causing artifacts with color \
> correction enabled so it is set up to src_alpha, one_minus_src alpha in that case.
> Now, inside KWinEffects:
> --
> A screen property is added for WindowPaintData.
> In kwinglutils, The fragment shaders are intercepted before being compiled and they \
> get a couple of lines of code inserted in order to do the color stuff. This happens \
> only when color correction is enabled, of course.
> And there is the big ColorCorrection class. The public and private stuff are well \
> separated.
> The private stuff consists of the private data and the D-Bus interface. Regarding \
> D-Bus, everything is async.
> The implementation basically manages a set of color lookup tables for different \
> outputs and for different window regions. These are taken via D-Bus. Each lookup \
> table has around 700 KB. I hope I am not wrong in assuming it's not that big of an \
> issue time-wise, since they are transferred only once or twice for an entire \
> session. I hope D-Bus doesn't do any time consuming business to transfer those \
> QVector's.
> In case of problems, it should not affect the rest of KWin in any way.
>
> Next priorities:
> --
> Implement per-window-region stuff. It should be a matter of extending KolorServer's \
> capabilities and doing some small modifications in SceneOpenGL::Window. The \
> ColorCorrection class from KWinEffects has everything prepared.
>
> Diffs
> -----
>
> kwin/kcmkwin/kwincompositing/main.cpp 7a89db4
> kwin/kcmkwin/kwincompositing/main.ui cff0f63
> kwin/libkwineffects/CMakeLists.txt f95d40e
> kwin/libkwineffects/kwineffects.h eb09d51
> kwin/libkwineffects/kwineffects.cpp 9cd9987
> kwin/libkwineffects/kwinglcolorcorrection.h PRE-CREATION
> kwin/libkwineffects/kwinglcolorcorrection.cpp PRE-CREATION
> kwin/libkwineffects/kwinglcolorcorrection_p.h PRE-CREATION
> kwin/libkwineffects/kwinglplatform.h 249ecdb
> kwin/libkwineffects/kwinglplatform.cpp 59ce7b2
> kwin/libkwineffects/kwinglutils.h 9b175b9
> kwin/libkwineffects/kwinglutils.cpp da0e7cc
> kwin/options.h 8069d7b
> kwin/options.cpp 50db58d
> kwin/scene-fragment.glsl 4b5424b
> kwin/scene.h be3acc4
> kwin/scene.cpp 28136b6
> kwin/scene_opengl.h dce2b7c
> kwin/scene_opengl.cpp 3f130b9
>
> Diff: http://git.reviewboard.kde.org/r/106141/diff/
>
>
> Testing
> -------
>
> Restarted KDED making sure Kolor-Manager is installed properly - this should make \
> the KDED module available.
> Restarted KWin, enabled color correction in KCM compositing, advanced tab.
>
> Played a bit with commands like:
> oyranos-monitor -d 0 XYZ.icc
> oyranos-monitor -d 1 Lab.icc
> Those set up particular profiles for the monitors. However, it seems there is a \
> problem with reverting to the normal ones. The code regarding that is taken \
> directly from CompICC, so I don't know whether it's a bug or a feature. Anyway, \
> it's from Kolor-Server.
> Apparently, everything works as planned. But I cannot distinguish visible \
> differences for the profiles used for the different monitors by default.
>
> After testing with the newest Oyranos, there is an issue at login, the custom color \
> profiles are not loaded at first because of an issue in Oyranos probably. It will \
> be fixed soon.
>
> Screenshots
> -----------
>
> Output 0 Lab.icc Output 1 XYZ.icc
> http://git.reviewboard.kde.org/r/106141/s/695/
>
>
> Thanks,
>
> Casian Andrei
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/106141/">http://git.reviewboard.kde.org/r/106141/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On August 23rd, 2012, 9:35 p.m., <b>Christoph \
Feck</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="http://git.reviewboard.kde.org/r/106141/diff/1/?file=80371#file80371line27" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/libkwineffects/kwinglcolorcorrection.h</a> <span \
style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td> <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: \
0; ">along with this program. If not, see \
<http://www.gnu.org/licenses/>.</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td> <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">27</font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span \
class="cp">#include <QMap></span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Unless you really need a \
specific order, use QHash instead of QMap for mapping.
All operations of QHash are near O(n), while QMap has O(log n).
(On a second look, you probably DO use the ordering, so that comment may be \
void)</pre> </blockquote>
<p>On August 23rd, 2012, 9:43 p.m., <b>Christoph Feck</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Of course, I meant QHash \
has O(1), not O(n) ... otherwise it wouldn't be faster. Sorry for the \
confusion.</pre> </blockquote>
<p>On August 23rd, 2012, 10:22 p.m., <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Just FTR: it's not \
that simple. QHash has a static overhead what makes QMap accesses cheaper for very \
few elements. Also insertion into QHash is more expensive.
If one only required a combined list one wants QList<QPair<>> but \
that's not the case here (while i'm not sure the map/hash is actually used at \
all)
While at it:
@Casian
did you mean to use QMap<Window, QList<QRect> > instead QMultiMap?</pre>
</blockquote>
<p>On August 24th, 2012, 2:23 p.m., <b>Casian Andrei</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This code is executed \
very rarely, so it wouldn't matter even if it would be O(n^3). Also, n should be \
quite small. I will keep in mind to use QHash in the future when it's advantages \
come into play.
I chose QMultiMap instead of QMap<Window, QList<QRect> > because, well, \
it looks shorter and fancier :) . I thought that if QMultiMap exists, perhaps it has \
some useful convenience methods for this kind of use.
The purpose of this map is to be able to get all the regions for a specific window \
right away - when drawing the window. The idea is that complexity and ugliness (like \
this multimap) should be set up once when the region profiles are fetched, and it \
should make life as easy as possible for the compositor when drawing the windows.
If there is a reason for using QMap<Window, QList<QRect> >, I will modify \
:)</pre> </blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Sorry, I \
just notice i forgot to publish this reply.
@Casian
please check whether this item is actually still up-to-date, I'll have a second \
look then.
-----
> The purpose of this map is to be able to get all the regions for a specific \
window right away
-> QMap<Window, QRegion>?
multimaps require repetitive data lookup (ie. you need to seach for all rect entries)
Depending on how often this is called and how complex your window regions become (eg. \
some applications used to shape drag and drop text windows...) it can have quite some \
performance impact.</pre> <br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On August 23rd, 2012, 9:35 p.m., <b>Christoph \
Feck</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; \
border-collapse: collapse; margin: 2px padding: 2px;"> <thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; \
font-size: 9pt; padding: 4px 8px; text-align: left;"> <a \
href="http://git.reviewboard.kde.org/r/106141/diff/1/?file=80373#file80373line81" \
style="color: black; font-weight: bold; text-decoration: \
underline;">kwin/libkwineffects/kwinglcolorcorrection_p.h</a> <span \
style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; \
"></pre></td> <td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: \
0; ">public:</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" \
align="right"><font size="2"></font></th> <td bgcolor="#c5ffc4" width="50%"><pre \
style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td> <th \
bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid \
#C0C0C0;" align="right"><font size="2">81</font></th> <td bgcolor="#c5ffc4" \
width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span \
class="k">virtual</span> <span class="o">~</span><span \
class="n">ColorCorrectionPrivate</span><span class="p">();</span></pre></td> </tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Usually, private d_ptr \
classes should not be virtual. If there is a reason, please explain.</pre> \
</blockquote>
<p>On August 24th, 2012, 2:23 p.m., <b>Casian Andrei</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I lack experience on \
this... Is this still an issue? Will fix right away if so.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; \
white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The \
question behind this is why the d pointer is a QObject. If it's just for those \
two slots, consider moving them up..
There's btw. no reason to repeat the virtual keyword in a derived class. (and \
actually i thing the coding style says "don't" - but i'm no way \
known an expert in that regard ;-)
You cannot withdraw virtuality and *never* should add it (ie. make a non virtual \
function virtual in a derived class - has usually little point either and can cause \
some headaches)</pre> <br />
<p>- Thomas</p>
<br />
<p>On October 27th, 2012, 9:56 a.m., Casian Andrei wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kwin, Thomas Lübking and Martin Gräßlin.</div>
<div>By Casian Andrei.</div>
<p style="color: grey;"><i>Updated Oct. 27, 2012, 9:56 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">These are the results of my GSoC project, for KWin.
This color correction needs KolorManager installed, master branch. That one needs \
Oyranos and additional color management dependencies. \
git://anongit.kde.org/kolor-manager.git http://www.oyranos.org/downloads
If it's not installed, the ColorCorrection class should fail without causing any \
issues to the user (that's if it's enabled from the KCM). Probably a \
notification could be appropriate in that case? "Failed to initialize CC because \
cannot contact Kolor-Server KDED..." something like that?
Change summary:
--
Add an option to kcmcompositing in the 'Advanced' tab, to enable or disable \
color correction. It is specified that it's experimental and it needs Kolor \
Manager. This implies some small changes to options.h and cpp.
Scene::finalPaintWindow code is moved into SceneOpenGL::performPaint.
SceneOpenGL has the declarations of some methods changed to include the screen number \
- those could be changed to pass around PaintData's probably. SceneOpenGL's \
newly implemented finalDrawWindow splits the rendering if color correction is enabled \
and there are multiple screens. Before painting for a particular screen, \
ColorCorrection::setupForOutput should be called.
There was a problem with the blending function causing artifacts with color \
correction enabled so it is set up to src_alpha, one_minus_src alpha in that case.
Now, inside KWinEffects:
--
A screen property is added for WindowPaintData.
In kwinglutils, The fragment shaders are intercepted before being compiled and they \
get a couple of lines of code inserted in order to do the color stuff. This happens \
only when color correction is enabled, of course.
And there is the big ColorCorrection class. The public and private stuff are well \
separated.
The private stuff consists of the private data and the D-Bus interface. Regarding \
D-Bus, everything is async.
The implementation basically manages a set of color lookup tables for different \
outputs and for different window regions. These are taken via D-Bus. Each lookup \
table has around 700 KB. I hope I am not wrong in assuming it's not that big of \
an issue time-wise, since they are transferred only once or twice for an entire \
session. I hope D-Bus doesn't do any time consuming business to transfer those \
QVector's.
In case of problems, it should not affect the rest of KWin in any way.
Next priorities:
--
Implement per-window-region stuff. It should be a matter of extending \
KolorServer's capabilities and doing some small modifications in \
SceneOpenGL::Window. The ColorCorrection class from KWinEffects has everything \
prepared. </pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Restarted KDED making sure Kolor-Manager is installed properly - this \
should make the KDED module available.
Restarted KWin, enabled color correction in KCM compositing, advanced tab.
Played a bit with commands like:
oyranos-monitor -d 0 XYZ.icc
oyranos-monitor -d 1 Lab.icc
Those set up particular profiles for the monitors. However, it seems there is a \
problem with reverting to the normal ones. The code regarding that is taken directly \
from CompICC, so I don't know whether it's a bug or a feature. Anyway, \
it's from Kolor-Server.
Apparently, everything works as planned. But I cannot distinguish visible differences \
for the profiles used for the different monitors by default.
After testing with the newest Oyranos, there is an issue at login, the custom color \
profiles are not loaded at first because of an issue in Oyranos probably. It will be \
fixed soon.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kwin/kcmkwin/kwincompositing/main.cpp <span style="color: \
grey">(7a89db4)</span></li>
<li>kwin/kcmkwin/kwincompositing/main.ui <span style="color: \
grey">(cff0f63)</span></li>
<li>kwin/libkwineffects/CMakeLists.txt <span style="color: \
grey">(f95d40e)</span></li>
<li>kwin/libkwineffects/kwineffects.h <span style="color: \
grey">(eb09d51)</span></li>
<li>kwin/libkwineffects/kwineffects.cpp <span style="color: \
grey">(9cd9987)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglcolorcorrection_p.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>kwin/libkwineffects/kwinglplatform.h <span style="color: \
grey">(249ecdb)</span></li>
<li>kwin/libkwineffects/kwinglplatform.cpp <span style="color: \
grey">(59ce7b2)</span></li>
<li>kwin/libkwineffects/kwinglutils.h <span style="color: \
grey">(9b175b9)</span></li>
<li>kwin/libkwineffects/kwinglutils.cpp <span style="color: \
grey">(da0e7cc)</span></li>
<li>kwin/options.h <span style="color: grey">(8069d7b)</span></li>
<li>kwin/options.cpp <span style="color: grey">(50db58d)</span></li>
<li>kwin/scene-fragment.glsl <span style="color: grey">(4b5424b)</span></li>
<li>kwin/scene.h <span style="color: grey">(be3acc4)</span></li>
<li>kwin/scene.cpp <span style="color: grey">(28136b6)</span></li>
<li>kwin/scene_opengl.h <span style="color: grey">(dce2b7c)</span></li>
<li>kwin/scene_opengl.cpp <span style="color: grey">(3f130b9)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/106141/diff/" style="margin-left: \
3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://git.reviewboard.kde.org/r/106141/s/695/"><img \
src="http://git.reviewboard.kde.org/media/uploaded/images/2012/08/23/cc_alter_6_400x100.png" \
style="border: 1px black solid;" alt="Output 0 Lab.icc Output 1 XYZ.icc" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic