El dilluns, 28 de setembre de 2020, a les 2:09:29 CEST, Martin (gzlist) va escriure: > Thank you for coming back to this Albert, and I hope you had a good > conference. > > On Sat, 26 Sep 2020 at 21:18, Albert Astals Cid <[email protected]> wrote: > > > > Or there is nothing to fix because we know the code works, which is the > > case here. > > To clarify, the current code is technically wrong in many places, but > guarded by the hard limit in the allocator, as described in my initial > message.
If it's guarded, it's not wrong. It's like saying that code this code if (!a) return; a->doSomething(); is technically wrong because if a is null it will crash and is only guarded by the if. Yes, that's what guards do, they make subsequent code free to assume stuff. > > > Doing changes for the sake of changing things is sometimes something we do, > > The changes are not "for the sake of [it]", they are to support the > goal "big images" as named in the title of this thread. > > > but we need to feel it, on those patches i wasn't feelint it. > > I don't know how to move forward in response to this. Make the patches correct (to by possibly wrong perception). > I'm unclear if your "feel it" has specific objections. You've not > stated that you would not accept any patches to the current allocator > limit, but perhaps that's the case? I already mentioned that you're not going to solve the "big image" support by increasing the allocator limit because there's always going to be bigger images that don't fit and that I think it's a better solution to just render N tiles if the image doesn't fit. I'm not 100% against a change to the allocator, but I need to be convinced that the extra code is worth the [edge case] scenario of wanting such big images. Cheers, Albert > > Martin > _______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
