I have fixed one obiviously wrong thing in
https://github.com/darktable-org/darktable/commit/e1b27201024c56747e81c46b9594290f20e1899b
It was found by Pascal Obry.
So now code actually reflects comment.
// last resort mem alloc for dead images. sizeof(dt_mipmap_buffer_dsc) +
dead image pixels (8x
Am 15.09.2014 21:10, schrieb Roman Lebedev:
> Hi.
>
> As far as i am aware, struct dt_mipmap_buffer_dsc is *not* being stored
> in on-disk mipmap cache.
>
>
> Aside from that, so far i have no more ideas.
>
If you can't fix it you need to revert the one or two commits in
question. You just can't
Please see also remine ticket #10109. darktable just crashes for me on
start due to commit ffbec14de21b0d3cf0b77e040308134c49632c22.
Ulrich
Am 15.09.2014 21:05, schrieb Pascal Obry:
> (Roman, I CC you as this seems a serious regression).
>
> I think this is a big problem with the mipmap cache.
>
Hi.
As far as i am aware, struct dt_mipmap_buffer_dsc is *not* being stored in
on-disk mipmap cache.
hanatos agrees:
>From IRC: (from related issue -
http://www.darktable.org/redmine/issues/10109)
hanatos: hello. i have a question about on-disc mipmap
cache, struct dt_mipmap_buffer_dsc and DT_
(Roman, I CC you as this seems a serious regression).
I think this is a big problem with the mipmap cache.
$ darktable -d cache
tell me that I have 131072 bucket for cache level 0. My setting is set
to 4096 for the Mb for the cache in the prefs. All this is fine and was
always this way.
I have
