camelot-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Camelot-discuss] Bindings librsvg


From: Sven Luther
Subject: Re: [Camelot-discuss] Bindings librsvg
Date: Thu, 13 Feb 2003 18:46:02 +0100
User-agent: Mutt/1.5.3i

On Thu, Feb 13, 2003 at 06:31:17PM +0100, Olivier Andrieu wrote:
>  > > Oui. En gros, un struct SDL_RWops est un object avec des méthodes
>  > > seek, read, write et close. L'API SDL comporte un SDL_RWFromFile,
>  > > un SDL_RWFromFP et un SDL_RWFromMem qui prennent respectivement,
>  > > un nom de fichier un FILE*, un void* en argument.
>  > 
>  > C'est donc un wrapper par dessus les operations courrantes d'acces
>  > de fichier ou memoire.
> 
> Oui.
> 
>  > BTW, est-ce que cela inclus aussi de pouvoir mmaper un fichier ?
> 
> Non.
> 
>  > Et est-ce que de toute facon, mmaper un fichier apporte un plus par
>  > rapport a l'ouvrir et le lire de facon normale ?
> 
> Bof, je sais pas trop. Pas grand chose à mon avis.

Le fait de mmaper, permet d'acceder au fichier directement comme si
c'etait un bout de memoire (un tableau de byte ?). J'imagine que les
modifications et les lectures sont fait au besoin seulement, ce qui peut
etre interessant si on accede qu'a des parties d'un fichier. (Comme ma
dameuse table de donnees) Mais c'est vrai que dans notre cas, c'est pas
forcement utile.

>  > > En résumé:
>  > > SDL_RW_FromFile -> c'est la seule API dispo actuellement pour ocamlsdl
>  > > SDL_RWFromMem   -> c'est nécessaire, je vais le faire (pas trés dur).
>  > 
>  > C'est suffisant pour l'instant, car on peut toujours lire le fichier
>  > compresse, et le stocker en memoire. 
> 
> C'est ce que je pense aussi.
> 
>  > cela utilise plus de memoire cependant. Noter cependant que l'API
>  > de librsvg permet d'ecrire les donnes dans le handle par bloc, et
>  > pas forcement en une seule fois, ce qui est utile je pense si on
>  > lit sur des sockets, ou si on a un tres gros fichier.
> 
> Oui. Encore faut-il que le renderer n'attendent pas d'avoir tout
> récupéré avant de commencer son boulot (faudrait regarder le source
> de librsvg pour savoir).

Oui, c'est aussi utile si on ne peut pas lire tout a la fois, comme cela
peut arriver par fois (lorsque read renvoie moins que ce qu'on avait
demander par exemple). J'imagine que librsvg n'attend pas d'avoir tout,
sinon elle devrait faire une copie en interne des donnees, ce qui me
parait lourd et peu efficace, et comme librsvg pretend etre plus rapide
que libpng pour rendre des images, je doute qu'ils fassent cela.

>  > BTW, pourquoi as-tu appeler le type des handle Rsvg.t et non Rsvg.handle ?
> 
> Bah, c'est usuel d'appeler un type `t' quand on en définit qu'un seul
> dans un module. De toutes façons, il n'est pas dans l'interface.

Mmm, a noter que tu recree un handler a chaque rendu, alors que librsvg
permettait de re-utiliser le handler. Je me demande pourquoi ils
faissait cela, mais peut-etre est-ce par soucis d'efficacite, il
faudrait voir si la creation/reservation du handler n'est pas lourde ou
quelque chose comme cela.

Amicalement,

Sven Luther




reply via email to

[Prev in Thread] Current Thread [Next in Thread]