Am 2018-01-18 23:05, schrieb Roman Gilg:
Yea, I thought that we could find maybe some intermediate state/goal
for the parallel rendering to which we can fallback when the overall
goal can't be achieved. I would add a line about the difficulty of
this project to the idea list. What do you think about this plan? But
if you still think that it's not a good idea, I'll remove it.
The task is huge and that's the main problem.
* Compositor needs to be woken up for each screen
* Which then goes into the scene to setup the information on what to
repaint
* which then goes into the effects
Now the main difficulty is that when e.g. a window is on both screens
the damage gets reset when the first screen is repainted. The complete
architecture is not fit for that. We would have to track the damage in a
screen aware manner (which is hardly possible with the lousy screen API
we have in KWin).
I spend lots of thinking about how to get the rendering of the
Compositor into an own thread - which goes into the same area. Ideally
each output would have a dedicated rendering thread. I started some work
on it, but probably completely unusable.
So a reasonable scope could be:
* improved internal screen API which allows a window to know on which
screens it is and damage per screen
* adjust the Compositor to be on top of that per screen damage
* maybe get the scene to be adjusted to use this information
That could be a neat way as we could introduce step by step without
removing the old code. So the result could be that KWin core can handle
it, but it would not be used yet as effects don't support it. Or only if
no effect is active.
Cheers
Martin
Your project ideas sound great. I will add these to the ideas list.
Also maybe David could mentor one of them.
On Thu, Jan 18, 2018 at 7:54 PM, Martin Flöser <mgraess...@kde.org>
wrote:
Am 2018-01-18 15:23, schrieb Roman Gilg:
I added two KWin project ideas:
https://community.kde.org/GSoC/2018/Ideas#KWin [1]
The first idea (parallel rendering) is IMHO too difficult for a
GSoC. The other idea sounds reasonable from scope.
Cheers
Martin
On Wed, Jan 17, 2018 at 6:18 PM, Roman Gilg <subd...@gmail.com>
wrote:
Hi,
Valorie, do we have until 23rd with project ideas? I didn't want to
mentor this year because I only was a GSoC student last year, but
since there are not yet many ideas from Plasma/KWin I might do it
anyway.
Nate, I want to get a rework of the Wayland Mouse KCM already into
Plasma 5.13. But the final GSoC submission is way after the release.
Libinput configuration on X might be still a valuable addition
(although I would like to see these resources better spent on some
other part of the Wayland session, in particular when you factor in
the late final submission next summer).
Cheers
Roman
On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham <pointedst...@zoho.com>
wrote:
I've submitted an idea for System Settings: Improve handling for
touchpads and mice with Libinput
https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput
[2]
[1]
This is pretty important going forward since most distros are
shipping with Libinput now, but our users aren't able to configure
their devices without resorting to editing xorg config files using a
different driver.
Nate
On 01/15/2018 06:13 AM, Dmitry Kazakov wrote:
Hi, Valorie!
I have just edited the list of Krita ideas, now we have 8 ideas, 4
of which are low-hanging fruits with localized optimizations of the
code. I hope that will help people who do not want to learn all
half-million lines of Krita code.
Speaking truly, I think I understand why there is so little effort
from people with the ideas. Since the last year Google forbids
students to apply more than 2 times, it means that most of the
applicants will be newcomers and, most probably, they will not be
able to prepare some extensive proposal/design for a project. It is
just too difficult to prepare a good proposal for a project so big
in size. So it might be that the quality of last year proposals
discouraged people from doing this work again.
The only way how we can solve the issue is to prepare very
scope-limited tasks, such that the students would not need to learn
all the code (in our case we just added AVX optimizations, which are
limited to a scope of a couple of classes). But that is not always
possible or makes sense for the some projects.
On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After
skipping GCi this past fall, are we now also considering skipping
GSoC? Or downsizing the number of students we are mentoring?
Without Ideas we will not get students. More important, we must
complete the Org application soon, and the Ideas page is the core of
that application.
This is good for your team and your project, in the long run. It
brings in new contributors and fresh ideas.
If you need some guidance, please read
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html
[3]
[2]
I should have linked to it for the last email.
Valorie
On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman
<valorie.zimmer...@gmail.com <mailto:valorie.zimmer...@gmail.com>>
wrote:
Hello GSoC mentors, and teams supporting mentors,
TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas [4] [3]
<https://community.kde.org/GSoC/2018/Ideas [4] [3]>; read
https://community.kde.org/GSoC. Now.
Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications
deadline
has passed.
The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure
that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.
Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:
1. commits must be made before the student proposal is
submitted,
and linked on that proposal, and
2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.
Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.
1. https://developers.google.com/open-source/gsoc/timeline [5] [4]
<https://developers.google.com/open-source/gsoc/timeline [5] [4]>
PS: If your team has an Idea, ensure that you have mentors for
it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!
Valorie
--
http://about.me/valoriez
--
Dmitry Kazakov
Links:
------
[1]
https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput
[2]
[2]
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html
[3]
[3] https://community.kde.org/GSoC/2018/Ideas [4]
[4] https://developers.google.com/open-source/gsoc/timeline [5]
Links:
------
[1] https://community.kde.org/GSoC/2018/Ideas#KWin
[2]
https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput
[3]
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html
[4] https://community.kde.org/GSoC/2018/Ideas
[5] https://developers.google.com/open-source/gsoc/timeline
