Extreme display corruption

[Nicolai Haehnle]

I concur that it's KDevelop's choice to use the raster engine by
default if it makes user experience better.

Speaking as somebody who's involved in the open source graphics driver
development, however: In general, we appreciate it if you let us know
about performance issues in the drivers. Otherwise, it'll never get
fixed and you'll stick with the raster default indefinitely, even
though native or opengl would be better solutions in the long run.

We appreciate it even more if you can help trace the problem down
(e.g. figure out which Render calls or whatever are responsible for
the slowdown) and perhaps provide a small self-contained application
that demonstrates the issue. After all, not everybody uses KDE.

(Most likely this problem is already known and only persists because
of lack of manpower - I'm personally only involved in the 3D part of
the drivers -, but from time to time we hear about surprising,
previously unknown, performance problems.)

cu,
Nicolai

On Tue, Sep 15, 2009 at 12:04 PM, Milian Wolff <mail at milianw.de> wrote:
> Kishore wrote:
>>
>> On Monday 14 Sep 2009 7:56:30 pm Kishore wrote:
>>>
>>> On Monday 14 Sep 2009 7:14:16 pm Andreas Pakulat wrote:
>>>>
>>>> On 14.09.09 16:26:36, Nikos Chantziaras wrote:
>>>>>
>>>>> On 09/14/2009 03:41 PM, Andreas Pakulat wrote:
>>>>>>
>>>>>> On 14.09.09 15:26:52, Nikos Chantziaras wrote:
>>>>>>>
>>>>>>> On 09/14/2009 02:20 PM, Milian Wolff wrote:
>>>>>>>>
>>>>>>>> Nikos Chantziaras, 14.09.2009:
>>>>>>
>>>>>> And with "native" KDevelop is simply
>>>>>> unusable.
>>>>>
>>>>> What exactly do you mean?  It seems to work great for me.
>>>>
>>>> It means that with the extensive highlighting we do for C++ scrolling
>>>> and
>>>> editing in katepart are horribly slow. We've found that factors
>>>> influencing this include compositing-effects as well as general PC
>>>> power.
>>>>
>>>> Or try a very long line thats dynamically wrapped inside the editor,
>>>> thats also very slow to edit with native engine, but really fast with
>>>> raster.
>>>>
>>>>>>> With all things considered, I don't think KDevelop should use raster
>>>>>>> on it's own; IMHO that's a choice the user should make; apps should
>>>>>>> follow the default unless the user says otherwise.
>>>>>>
>>>>>> Except if the default makes the app in question unusable. We want to
>>>>>> provide a nice experience from the start, without the User having to
>>>>>> dig up some obscure cmdline option.
>>>>>
>>>>> This way we end up with each app circumventing defaults.  Imagine if
>>>>> each app would do that.  Users would have to configure each and every
>>>>> one separately and we're back to the 1980's.  Surely I'm not the only
>>>>> one who sees something wrong about this approach?  On most systems, Qt
>>>>> is not configured with raster as default, and there's a reason for
>>>>> that.
>>>>
>>>> How do you measure "most systems"? I've got 3 at hand and all of them
>>>> use
>>>> raster by default. There are in fact only few desktop apps that cannot
>>>> use raster at all because they rely on certain implementation details of
>>>> native and the KDE apps among them apply the same code we do to force
>>>> their app to use native instead of raster - ignoring my configured Qt
>>>> default ;)
>>>>
>>>>> In any event, I don't feel too strongly about it, since now I know how
>>>>> to fix it.  Just mentioning that this might bite lots of people and it
>>>>> might be a good idea to make this configurable in KDevelop and using
>>>>> Qt's default by default.
>>>>
>>>> It already is configurable by using the cmdline switch supplied by Qt.
>>>
>>> Thanks for this discussion. On my Samsung NC10 (Netbook with intel
>>>  graphics) KDevelop started to feel really slow the last couple of weeks.
>>>  After this discussion, i wanted to give it a try and launched kdevelop
>>>  with - graphicssystem native. It is so much faster! Relaunching without
>>>  that option make is slow again!
>>>
>>> May be reconsider that decision?
>>
>> For more information, this netbook is running Kubuntu Karmic with intel
>> graphics driver version 2.8.1 using xserver-xorg version 1.6.3
>> Qt: 4.5.2
>> KDE: 4.3.1 (KDE 4.3.1)
>> KDevelop: 3.9.95 (using KDevPlatform 0.9.95) (compiled from sources)
>
> What kind of intel is that? I have one myself at home and will give you my
> setup later on. Though I have still Jaunty, but a lot of backported intel
> drivers.
>
> I'll get back to you later today.
>
>
> --
> Milian Wolff
> http://milianw.de
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>