Extreme display corruption

[Milian Wolff]

Nicolai Haehnle wrote:
> 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.)

Take a look at that:

https://bugs.kde.org/show_bug.cgi?id=169549

There are a few test cases attached.

> 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