https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
CC||nilsoc...@gmail.com
--- Comment #39 from Nate
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
CC||mywtf...@gmail.com
--- Comment #38 from Nate
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #37 from Tobias Deiminger ---
(In reply to Tobias Deiminger from comment #36)
> After sleeping over it, I can't believe my own words. How could uchar*
> QImageData::data happen to point to stack? Give me some time to double check
> and
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #36 from Tobias Deiminger ---
(In reply to Tobias Deiminger from comment #35)
> PagePrivate::PixmapObject::m_pixmap were NOT in heap, but on stack.
> data = 0x7fffc6093010 // Here's the large raw pixmap
> //
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #35 from Tobias Deiminger ---
(In reply to Albert Astals Cid from comment #34)
> That code is only used if you have QT_XCB_NATIVE_PAINTING environment
> variable set that i hope you're not since it's experimental
The variable wasn't set. So
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #34 from Albert Astals Cid ---
(In reply to Tobias Deiminger from comment #33)
> (In reply to Christoph Feck from comment #32)
> > > Following this theory, I shouldn't be able to find bitmaps in heap.
> >
> > Your theory is wrong. Read
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #33 from Tobias Deiminger ---
(In reply to Christoph Feck from comment #32)
> > Following this theory, I shouldn't be able to find bitmaps in heap.
>
> Your theory is wrong. Read QPixmap source.
I did and found
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #32 from Christoph Feck ---
> Following this theory, I shouldn't be able to find bitmaps in heap.
Your theory is wrong. Read QPixmap source.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #31 from Rooty ---
(In reply to Albert Astals Cid from comment #28)
> I'm not going to answer further in this bug because i don't feel compelled
> to have a discussion with people that saying things like "no way a 90kb PDF
> can take XX Mb
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #30 from Tobias Deiminger ---
(In reply to Albert Astals Cid from comment #28)
> *BUT* this may actually be a manifestation of "glibc is useless and doesn't
> actually free memory when you tell it to" that i workarounded at
>
https://bugs.kde.org/show_bug.cgi?id=388854
Tobias Deiminger changed:
What|Removed |Added
CC||haxti...@posteo.de
--- Comment #29 from
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #28 from Albert Astals Cid ---
I'm not going to answer further in this bug because i don't feel compelled to
have a discussion with people that saying things like "no way a 90kb PDF can
take XX Mb of memory" as if they knew anything about
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #27 from Rooty ---
(In reply to Oliver Sander from comment #26)
> I am not saying that speed/memory consumption of Okular are great and cannot
> be improved. However, the path from to the rather vague "Okular uses lots of
> memory" to
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #26 from Oliver Sander ---
I am not saying that speed/memory consumption of Okular are great and cannot be
improved. However, the path from to the rather vague "Okular uses lots of
memory" to specific improvements to the code is long and
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #25 from Rooty ---
(In reply to Oliver Sander from comment #24)
> I don't think that this would help. The argument would then be that the
> "use little memory"-option has its price, which is slower loading times.
>
> What is needed is
https://bugs.kde.org/show_bug.cgi?id=388854
Oliver Sander changed:
What|Removed |Added
CC||oliver.san...@tu-dresden.de
--- Comment #24
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #23 from Rooty ---
(In reply to Brennan Kinney from comment #21)
> (In reply to Nate Graham from comment #20)
> > Thanks for the additional information, Brennan. However, as previously
> > noted, high memory usage of the sort described by
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #22 from Rooty ---
(In reply to Brennan Kinney from comment #21)
> (In reply to Nate Graham from comment #20)
> > Thanks for the additional information, Brennan. However, as previously
> > noted, high memory usage of the sort described by
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #21 from Brennan Kinney ---
(In reply to Nate Graham from comment #20)
> Thanks for the additional information, Brennan. However, as previously
> noted, high memory usage of the sort described by you and others in this
> ticket is not
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
Resolution|FIXED |INVALID
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bugs.kde.org/show_bug.cgi?id=388854
Brennan Kinney changed:
What|Removed |Added
Version|0.25.0 |1.4.2
Platform|Other
https://bugs.kde.org/show_bug.cgi?id=388854
Brennan Kinney changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
https://bugs.kde.org/show_bug.cgi?id=388854
Rooty changed:
What|Removed |Added
CC||zy...@gmx.us
--- Comment #18 from Rooty ---
it's
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
CC||looriin...@gmail.com
--- Comment
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #16 from Sasha ---
Thank you!
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=388854
Albert Astals Cid changed:
What|Removed |Added
Resolution|--- |INVALID
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #14 from Sasha ---
And some about memory leaks. I tried to move up and down thrue the ocument from
side by side and after a couple of times i have about 50 additional megabites
in my RAM. But couple of minutes ago the
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #13 from Sasha ---
So thank you for your responding! I catched the reason of this behavior. But
what will be with the program if i want to read for example 500 pages or work
with some documents with lower number of
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #12 from Nate Graham ---
So what are we doing with this bug? Do we consider this to be normal behavior?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #11 from Nate Graham ---
Yes, I opened Okular with the document and left it open for a few hours. I
didn't observe any memory leak; usage was static. So I assumed that the
reporter was referring to memory consumed by
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #10 from Albert Astals Cid ---
(In reply to Albert Astals Cid from comment #9)
> Question since you changed the subject of the bug, have you verified that
> there is actually no memory bug?
memory bug -> memory leak
--
You
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #9 from Albert Astals Cid ---
Question since you changed the subject of the bug, have you verified that there
is actually no memory bug?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #8 from Nate Graham ---
If you don't see any problems with Okular's memory usage, then go ahead and
close the bug. No reason to leave it open if we don't intend to make any
changes.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=388854
Albert Astals Cid changed:
What|Removed |Added
Ever confirmed|1 |0
https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #6 from Albert Astals Cid ---
(In reply to Nate Graham from comment #5)
> Yes, but is the amount reasonable?
You have it available, do you prefer the memory to lay around being unused?
> 1.17 Gb RAM / 257 pages = 4.5 Mb per
https://bugs.kde.org/show_bug.cgi?id=388854
Nate Graham changed:
What|Removed |Added
Summary|A very big volume of RAM|Okular uses a very large
38 matches
Mail list logo