GNOME Bugzilla – Bug 329651
gparted crashes when choosing a colordepth of 16 bits
Last modified: 2006-03-13 03:47:59 UTC
Steps to reproduce: 1. boot livecd and choose 16 bits colordepth 2. start gparted Stack trace: Other information: Hi, i filed this bug in the livecd section since i can only reproduce it on the livecd. I'm already on it and try to fix it in gparted, but i'd like to have your insights in this matter. thanks!
What type of graphics changes did you make from 0.0.9 to 0.1/0.2? I did notice in the new versions your not linking the disk/about/help icons anymore. Xfce for some reason doesn't seem to like them at 8 or 16 depth. 0.0.9 doesn't segfault on livecd-0.2 at 16 btw. It has to be some sort of a simple graphics error, obviously a problem with Xfce, because 0.2 runs on the CD using Fluxbox at any depth. It's the only thing that comes to mind right now.
( hi patrick ! ) news: i have tried 640x480 and 800x600 and 1024x768 and 1280x1024 and i've found that: on all these modes, choosing 8 bit or 16 bit xolor depth, the gparted segfaults. all the other color depths worked ok. that suggests you're right with the above comment.
https://bugs.freedesktop.org/show_bug.cgi?id=4505 check this out...
Well, i know for a fact it's related to the colored pixbufs in the treeview. When i comment them everything works fine. I didn't have time to investigate any further, but i will as soon as i have time.
that bug at freedesktop looks interesting indeed!
"colored pixbufs in the treeview" Can you tell me more about this. I really don't want you to alter Gparted code that works to fix a problem that's only on the cd. It seems really strange that my Slackware system I use everyday has exactly the same deps as the CD and it doesn't segfault. I've spent hours and hours and hours trying to fix this and it seems I've hit a brick wall. What the heck is missing?
Hi Patrick, sorry for the delay, i've been quite busy with school lately. I'm not sure what causes this issue, but i'll try to find some time to do the necessary research. It's quite weird we haven't had more reports on this, maybe most people run the livecd using a colordepth of 24 bits and never encounter this issue.
My worst fears. It's Xvesa not liking 16 or 8 bits with cairo. I tested this last night. The CD works with xorg and slackware fails with xvesa. God this sucks. Most people don't notice because most computers built in the last ten years support 24 bit color. I wonder what types of machines people are having these failers on?
hi patrick one computer i had these failure is p2/500 with 320 megs ram and: s3 trio 3d/dx video card and an old 14" analog targa monitor. the other computer is barton/1833 (2500+) 512 megs of ram, nvidia fx5200 / 64 megs vram, and acer al 1715.the problem hitted on the first computer although most other tests were done on the second computer. and probably, even the first one can handle 24 bit color depth, but i was tempted to try the "safe" setting, you know :) but one reason wich probably push people to lower resolution/color depth is the gain in speed (of X) on old machines ....
Plors and I discussed this and decided to drop support for 8 and 16 depth. These are my reasons: 1. I did some research and xvesa at 24 bits is going to run faster than xorg at 16. 2. 99% of monitors and video cards in the Pentium 1 days could run 24 depth. 3. I'm not going back to xorg and bloat the cd to 50mb to support computers this old. Xorg is much slower. 4. GParted is not going to stop using cairo. 5. The CD runs good on a P166 I have at work. It takes longer to boot (duh), but once X started it ran almost as fast as my Intel 865 P4 machine. Reading the off the CD was much slower than anything X was causing. 6. The vast majority of people using this CD would rather have the nicer tree view than the minimal resoure savings (if any human could tell) of 16 depth. I hope this doesn't make anybody too upset :)
Plors and I discussed this and decided to drop support for 8 and 16 depth. These are my reasons: >1. I did some research and xvesa at 24 bits is going to run faster than xorg at >16. > >2. 99% of monitors and video cards in the Pentium 1 days could run 24 depth. > >3. I'm not going back to xorg and bloat the cd to 50mb to support computers >this old. Xorg is much slower. > Major mistake here. You *DON'T* want speed here. YOU WANT SOMETHING THAT WORKS ON WHATEVER HARDWARE YOU THROW AT IT. And quite frankly the version of xvesa you're using just doesn't cut it. It's basically crap. I don't know where you got it from, but you would better off dumping it and using the Xorg/Xvesa setup from either Puppy Linux or Damn Small Linux instead because they actually work as they should. In fact I would recommend the Puppy Linux approach because it lets you choose which one (Xorg or Xvesa) works best with your harware.
"And quite frankly the version of xvesa you're using just doesn't cut it. It's basically crap." No. I think it's your computer that's crap. Your money has been refunded.
Let's see....you've got an crippled X_server on your hands that *CAN'T* support 8 and 16 (and I suspect 24bit) graphics which other distros which use the same X-Server (Puppy and Damn Small) *DO* support without blowing up and you don't think the version you're using isn't screwed up?
Let's see....yawn. Like I said before. Your money has been refunded. Go troll someplace else.
please STOP using words like 'crap'! This is a place for sharing information and knowledge on a proffesional level. Nobody gains anything from shouting at each other like this. @Chis lee: if you think something could be improved please state so in a polite, respectfull manner. We're not here to do the users bidding and you are always free to choose another livecd.
Hey, sorry Bart. I was accually trying to be funny. It's this here interweb stuff makes it hard to tell ya all sometimes. Yeehaaa. :) This issue is closed. Next to nobody is going to care.
It was cario. 8 and 16 both work without touching X. hmmm Problem fixed...