Extreme display corruption

[Milian Wolff]

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