Vlákno názorů k článku Anatomie grafického formátu GIF od su - \mathfrak{M}ĦĒNJMARCHON - Na firefoxe Gentoo x86 sa zobrazi OK, aj...
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Na firefoxe Gentoo x86 sa zobrazi OK, aj ked som chvilu nevidel scrollbary, pretoze mi ho automaticky zmensilo (zoom out). Po zoom in vsetko spravne (velky biely stvorec, ovsem ten jeden pixel vpravo dole neviem najst, mozno som slepy ;-)).
gthumb, gqview tvrdia, ze gif je 1x1 (integer overflow?), gimp to jemne nerozdychal (mozno by rozdychal, keby ho chvilu necham, alebo by ho jadro zakillovalo pri mallocu na 2^32 ;-)). -
Pavel TišnovskýZlatý podporovatelNo, ten pixel jsem nedaval uplne do rozku (staci se mrknout hexa editorem na ten GIF, posloupnost FF FF FF FF tam je nahrazena FE FF FE FF), ale trosku nahoru, protoze jsem narazil na podivne chovani napriklad IE, ktery pri tak velkem obrazku trosku spodku urizne. Je to cca 20 pixelu a zrovinka ten pixel nebyl videt. Vysvetluju si to spis divnym chovanim scrollbaru (ty maji tusim pocitadlo pouze 16bitove) nez IE.
Pokud GIMP opravdu alokuje vsechny "dlazdicky" (tak nejak vevnitr s obrazky pracuje ne?), tak to bude chtit dokoupit dalsi ramku :-)
Nezkusi to nekdo ve slavnem Photoshopu? -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Co si pamatam, Linux ma "optimisticky malloc". Teda malloc vrati non-NULL pointer, ale to este neznamena, ze ta pamat tam dakde sa da naozaj mmap()nut. Keby teda gimp nechcel hned tu pamat naplnit bielymi pixelmi, rozdychal by to. Nicmene mam pocit, ze pustil loop malloc()/decode_and_fill_with_pixels().
Pripadne si zapojim mozog do tretieho slotu na ramku, najprv trepanacia, potom nejake kabliky, heh. -
Pavel TišnovskýZlatý podporovatelJojo, dokonce jsem nekde cetl, ze by OS principielne vzdycky mel na malloc() vratit !NULL, protoze prace s pameti aplikaci stejne nezajima, resp. pokud pamet neni, tak se to aplikace dozvi nejakym zajimavejsim zpusobem (SIGTERM apod. :-)))
