Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38262 > unrolled thread

how do you block the GUI repaints?

Back to article view | Back to comp.lang.java.programmer

Contents

  how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-22 10:59 -0700
    Re: how do you block the GUI repaints? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2018-05-22 13:22 -0500
      Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-22 13:00 -0700
        Re: how do you block the GUI repaints? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-05-22 16:29 -0400
          Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-22 13:51 -0700
            Re: how do you block the GUI repaints? Martin Gregorie <martin@mydomain.invalid> - 2018-05-22 21:41 +0000
            Re: how do you block the GUI repaints? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-05-22 18:03 -0400
              Re: how do you block the GUI repaints? Andreas Leitgeb <avl@logic.at> - 2018-05-22 22:22 +0000
                Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 07:55 -0700
                  Re: how do you block the GUI repaints? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-05-23 11:06 -0400
                    Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 08:19 -0700
    Re: how do you block the GUI repaints? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-05-22 14:43 -0400
      Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-22 13:20 -0700
        Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-22 22:47 +0200
          Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-22 13:58 -0700
            Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-23 04:30 +0200
              Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 05:54 -0700
                Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-23 15:58 +0200
                  Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 07:26 -0700
                    Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-23 16:30 +0200
                      Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 07:48 -0700
                        Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-23 18:46 +0200
                          Re: how do you block the GUI repaints? Eric Douglas <e.d.programmer@gmail.com> - 2018-05-23 10:51 -0700
                            Re: how do you block the GUI repaints? Daniele Futtorovic <da.futt.news@laposte.net> - 2018-05-23 22:35 +0200

Page 1 of 2  [1] 2  Next page →

#38262 — how do you block the GUI repaints?

I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.

Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.

[toc] | [next] | [standalone]

#38263

On 5/22/2018 12:59, Eric Douglas wrote:
> I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
> 
> Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
> 

Buffer the chunks?

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#38265

On Tuesday, May 22, 2018 at 2:22:50 PM UTC-4, Knute Johnson wrote:
> On 5/22/2018 12:59, Eric Douglas wrote:
> > I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
> > 
> > Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
> > 
> 
> Buffer the chunks?
> 
> -- 
> 
> Knute Johnson

Is there an efficient way to buffer?  Is reading bytes from a file into a buffer then pushing them into a JTextArea going to take twice the memory?  How big can a buffer be?

I tried creating the maximum buffer and got the error "java.lang.OutOfMemoryError: Requested array size exceeds VM limit".  I'm using java.nio.ByteBuffer.allocate() for a java.nio.channels.FileChannel.read().  I'm trying to see if it can read a 8284958067 byte text file into the JTextArea, or how much I can get it to display at one time.  If ByteBuffer.allocate() is throwing a memory error using Integer.MAX_VALUE, which should also be the maximum allowed for one String size should the VM allow it, I'm definitely going to have a problem using JTextArea.insert() just once, or down to as few chunks as possible.

I tried just doing a loop on the file read with smaller sizes to see if there's a memory limit to JTextArea and what would happen if I hit that on insert.  It seemed to hold quite a bit but I got annoyed that the frame was not responding if I called too many inserts unless I throw a Timer.sleep in between them, but it doesn't make sense to take an extra half second on every insert for no apparent reason.  I can make the control not editable while I'm inserting so there's no reason to lock up the EDT trying to display after each insert.

[toc] | [prev] | [next] | [standalone]

#38267

On 5/22/2018 4:00 PM, Eric Douglas wrote:
> On Tuesday, May 22, 2018 at 2:22:50 PM UTC-4, Knute Johnson wrote:
>> On 5/22/2018 12:59, Eric Douglas wrote:
>>> I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
>>>
>>> Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
>>>
>>
>> Buffer the chunks?
>>
>> -- 
>>
>> Knute Johnson
> 
> Is there an efficient way to buffer?  Is reading bytes from a file into a buffer then pushing them into a JTextArea going to take twice the memory?  How big can a buffer be?
> 
> I tried creating the maximum buffer and got the error "java.lang.OutOfMemoryError: Requested array size exceeds VM limit".  I'm using java.nio.ByteBuffer.allocate() for a java.nio.channels.FileChannel.read().  I'm trying to see if it can read a 8284958067 byte text file into the JTextArea, or how much I can get it to display at one time.

... which will be a little less unless you have a truly enormous
display screen.  Eight gigabytes on a typical desktop of around
two megapixels comes to around two thousand characters per pixel
(assuming 2+ bytes per character), which will tax most people's
visual acuity somewhat ...

> I tried just doing a loop on the file read with smaller sizes to see if there's a memory limit to JTextArea and what would happen if I hit that on insert.  It seemed to hold quite a bit but I got annoyed that the frame was not responding if I called too many inserts unless I throw a Timer.sleep in between them, but it doesn't make sense to take an extra half second on every insert for no apparent reason.  I can make the control not editable while I'm inserting so there's no reason to lock up the EDT trying to display after each insert.

     I'm not 100% certain, but I don't think non-editability will
affect the repainting.  The EDT will still try to keep the display
up-to-date with the state of the displayed things, whether the
updates come from the user or from the program.

     But, but, but: Why in the ever-lovin' blue-eyed world are you
trying to draw four gigacharacters (perhaps more!) on a display?
That's a three-million-page book; who will read it?  What are you
trying to do?

-- 
esosman@comcast-dot-net.invalid
Nine hundred seventy-four days to go.

[toc] | [prev] | [next] | [standalone]

#38269

On Tuesday, May 22, 2018 at 4:30:07 PM UTC-4, Eric Sosman wrote:
> On 5/22/2018 4:00 PM, Eric Douglas wrote:
> > On Tuesday, May 22, 2018 at 2:22:50 PM UTC-4, Knute Johnson wrote:
> >> On 5/22/2018 12:59, Eric Douglas wrote:
> >>> I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
> >>>
> >>> Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
> >>>
> >>
> >> Buffer the chunks?
> >>
> >> -- 
> >>
> >> Knute Johnson
> > 
> > Is there an efficient way to buffer?  Is reading bytes from a file into a buffer then pushing them into a JTextArea going to take twice the memory?  How big can a buffer be?
> > 
> > I tried creating the maximum buffer and got the error "java.lang.OutOfMemoryError: Requested array size exceeds VM limit".  I'm using java.nio.ByteBuffer.allocate() for a java.nio.channels.FileChannel.read().  I'm trying to see if it can read a 8284958067 byte text file into the JTextArea, or how much I can get it to display at one time.
> 
> ... which will be a little less unless you have a truly enormous
> display screen.  Eight gigabytes on a typical desktop of around
> two megapixels comes to around two thousand characters per pixel
> (assuming 2+ bytes per character), which will tax most people's
> visual acuity somewhat ...

Obviously you can literally look at the entire file at once.  That's why it's in a JScrollPane.  When I say how much it can display I mean how much text it can store, while of course you have to scroll to see it.

> 
> > I tried just doing a loop on the file read with smaller sizes to see if there's a memory limit to JTextArea and what would happen if I hit that on insert.  It seemed to hold quite a bit but I got annoyed that the frame was not responding if I called too many inserts unless I throw a Timer.sleep in between them, but it doesn't make sense to take an extra half second on every insert for no apparent reason.  I can make the control not editable while I'm inserting so there's no reason to lock up the EDT trying to display after each insert.
> 
>      I'm not 100% certain, but I don't think non-editability will
> affect the repainting.  The EDT will still try to keep the display
> up-to-date with the state of the displayed things, whether the
> updates come from the user or from the program.
> 
>      But, but, but: Why in the ever-lovin' blue-eyed world are you
> trying to draw four gigacharacters (perhaps more!) on a display?
> That's a three-million-page book; who will read it?  What are you
> trying to do?
> 

Of course making it non editable doesn't automagically affect the repaint, I tried that.  I'm just saying I should be able to tell it not to repaint because the user can't do anything to change it between paints.  The display doesn't matter until it's done loading.  There's another control trying to show the loading progress, but it can't update a JProgressBar while it's doing a lot of inserts because the EDT is all tied up with this unnecessary painting.

[toc] | [prev] | [next] | [standalone]

#38271

On Tue, 22 May 2018 13:51:43 -0700, Eric Douglas wrote:

> Of course making it non editable doesn't automagically affect the
> repaint, I tried that.  I'm just saying I should be able to tell it not
> to repaint because the user can't do anything to change it between
> paints.  The display doesn't matter until it's done loading.  There's
> another control trying to show the loading progress, but it can't update
> a JProgressBar while it's doing a lot of inserts because the EDT is all
> tied up with this unnecessary painting.
>
Have you tried creating an empty JTextArea, i.e. one with no Document or 
content, then filling a Document, e.g. a PlainDocument, with all the 
material that will be displayed before attaching it to the JTextArea, i.e.

// Create JTextArea something like this:
 
JtextArea jta = new JTextArea(rows, cols); 

// when the View is being created, i.e. with NO Document and no content.
// Now create the Document, insert content into it and finally
// link it to the JTextArea...

   Plain Document doc = new PlainDocument();
   doc.insertString(0, contentString, new SimpleAttributeSet());
   jta.setDocument(doc);

It seems to me that thats as good a way as any of stopping the JTextArea 
from firing multiple display refreshes while the Document is being filled 
as any. 

Usual caveats: it looks possible from reading the class specs but I 
haven't tried it.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#38272

On 5/22/2018 4:51 PM, Eric Douglas wrote:
> On Tuesday, May 22, 2018 at 4:30:07 PM UTC-4, Eric Sosman wrote:
>> On 5/22/2018 4:00 PM, Eric Douglas wrote:
>>> On Tuesday, May 22, 2018 at 2:22:50 PM UTC-4, Knute Johnson wrote:
>>>> On 5/22/2018 12:59, Eric Douglas wrote:
>>>>> I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
>>>>>
>>>>> Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
>>>>>
>>>>
>>>> Buffer the chunks?
>>>>
>>>> -- 
>>>>
>>>> Knute Johnson
>>>
>>> Is there an efficient way to buffer?  Is reading bytes from a file into a buffer then pushing them into a JTextArea going to take twice the memory?  How big can a buffer be?
>>>
>>> I tried creating the maximum buffer and got the error "java.lang.OutOfMemoryError: Requested array size exceeds VM limit".  I'm using java.nio.ByteBuffer.allocate() for a java.nio.channels.FileChannel.read().  I'm trying to see if it can read a 8284958067 byte text file into the JTextArea, or how much I can get it to display at one time.
>>
>> ... which will be a little less unless you have a truly enormous
>> display screen.  Eight gigabytes on a typical desktop of around
>> two megapixels comes to around two thousand characters per pixel
>> (assuming 2+ bytes per character), which will tax most people's
>> visual acuity somewhat ...
> 
> Obviously you can literally look at the entire file at once.  That's why it's in a JScrollPane.  When I say how much it can display I mean how much text it can store, while of course you have to scroll to see it.

     Three million pages' worth of scrolling?  Put yourself down for
an extended stay at the Carpal Tunnel Clinic ...

     It doesn't seem to me that "Dump it in a text display" is a
reasonable way to present this quantity of data.  Nobody can read
that much text.

-- 
esosman@comcast-dot-net.invalid
Nine hundred seventy-four days to go.

[toc] | [prev] | [next] | [standalone]

#38273

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>      It doesn't seem to me that "Dump it in a text display" is a
> reasonable way to present this quantity of data.  Nobody can read
> that much text.

Maybe it's just needed to display an EULA ...

[toc] | [prev] | [next] | [standalone]

#38281

On Tuesday, May 22, 2018 at 6:22:08 PM UTC-4, Andreas Leitgeb wrote:
> Eric Sosman wrote:
> >      It doesn't seem to me that "Dump it in a text display" is a
> > reasonable way to present this quantity of data.  Nobody can read
> > that much text.

I don't know what it's limits are on the amount of text it can hold at one time.  On a large file I'm normally just looking at the beginning and/or the end, and I'd like to add a search function.  If for some reason we need to read the whole thing we may need to enlist some congressional aides.  If we're just jumping around, the JScrollPane seems efficient thus far.

> 
> Maybe it's just needed to display an EULA ...

lol

[toc] | [prev] | [next] | [standalone]

#38282

On 5/23/2018 10:55 AM, Eric Douglas wrote:
> On Tuesday, May 22, 2018 at 6:22:08 PM UTC-4, Andreas Leitgeb wrote:
>> Eric Sosman wrote:
>>>       It doesn't seem to me that "Dump it in a text display" is a
>>> reasonable way to present this quantity of data.  Nobody can read
>>> that much text.
> 
> I don't know what it's limits are on the amount of text it can hold at one time.  On a large file I'm normally just looking at the beginning and/or the end, and I'd like to add a search function.  If for some reason we need to read the whole thing we may need to enlist some congressional aides.  If we're just jumping around, the JScrollPane seems efficient thus far.

     Okay, it's your program, do as you like.  I'll offer just
one more back-of-the-envelope calculation in one final attempt
to dissuade you from your folly:

     - Assume three million pages' worth of content (or maybe
       six million if it's a one-byte-per-character encoding)

     - Assume a screen height of around 2000 pixels (mine is
       about half that, but perhaps you've got Big Hardware)

     - It follows that moving the scroll thumb by one pixel
       will move the view by 3000000/2000 = 1500 pages.

     - ... that is, to advance by one page you should move the
       scroll thumb by two-thirds of one millipixel.

     Have fun navigating!

-- 
esosman@comcast-dot-net.invalid
Nine hundred seventy-three days to go.

[toc] | [prev] | [next] | [standalone]

#38284

On Wednesday, May 23, 2018 at 11:07:04 AM UTC-4, Eric Sosman wrote:
>      Okay, it's your program, do as you like.  I'll offer just
> one more back-of-the-envelope calculation in one final attempt
> to dissuade you from your folly:
> 
>      - Assume three million pages' worth of content (or maybe
>        six million if it's a one-byte-per-character encoding)
> 
>      - Assume a screen height of around 2000 pixels (mine is
>        about half that, but perhaps you've got Big Hardware)
> 
>      - It follows that moving the scroll thumb by one pixel
>        will move the view by 3000000/2000 = 1500 pages.
> 
>      - ... that is, to advance by one page you should move the
>        scroll thumb by two-thirds of one millipixel.
> 
>      Have fun navigating!
> 

Ha, perhaps we're have to break that up into pages and show one page at a time.

So I found where to test for squares.
For some reason Java comes with a generic checker.  I'm guessing JTextArea default is ascii, so
CharsetEncoder enc = Charset.forName("US-ASCII").newEncoder();
if (enc.canEncode(s)) {
// JTextArea insert
} else {
// convert to hex view (or test the string one character at a time and somehow convert the non-displayables to something displayable)
}

Probably a better answer is to use the font assigned to the control (https://docs.oracle.com/javase/8/docs/api/java/awt/Font.html#canDisplayUpTo-java.lang.String-), then just have to figure out what to do with that result.  If it can't display it, what can we convert it to?

[toc] | [prev] | [next] | [standalone]

#38264

On 5/22/2018 1:59 PM, Eric Douglas wrote:
> I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
> 
> Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.

     You're on the right track: Do it in the model.  For example,
the TableModel you implemented replaces

	update cell
	fire event
	update cell
	fire event
	update cell
	fire event
	...

with

	update cell
	update cell
	update cell
	...
	fire mega-event

and you could, perhaps, go on to

	bulk-update many cells
	fire mega-event

     Do similarly with the other controls that bother you.

     Also (and depending on the nature of your updates), you may
gain by firing "specific" events instead of "catch-all" events.
For example, a JTable might be more responsive if its model fired
events reporting updates to three individual cells than if it
fired "the whole table changed" events.  (This goes somewhat
against the "fire mega-event" suggestion above, but that just
means that engineering is the art of striking balances.)

-- 
esosman@comcast-dot-net.invalid
Nine hundred seventy-four days to go.

[toc] | [prev] | [next] | [standalone]

#38266

On Tuesday, May 22, 2018 at 2:43:21 PM UTC-4, Eric Sosman wrote:
> On 5/22/2018 1:59 PM, Eric Douglas wrote:
> > I made a custom JTable, but it has a separate model.  I wanted to be able to update a lot of cell values and just have it repaint the whole table when I'm done, so I just made a custom model, overrode the fire method to not tell it to repaint while I'm loading it, and call one fireTableChanged when I'm done.
> > 
> > Now what's the easiest way to do this with other controls?  I made a custom JTextArea, I try to insert a lot of text one chunk at a time, and it locks up the EDT issuing repaint requests.
> 
>      You're on the right track: Do it in the model.  For example,
> the TableModel you implemented replaces
> 
> 	update cell
> 	fire event
> 	update cell
> 	fire event
> 	update cell
> 	fire event
> 	...
> 
> with
> 
> 	update cell
> 	update cell
> 	update cell
> 	...
> 	fire mega-event
> 
> and you could, perhaps, go on to
> 
> 	bulk-update many cells
> 	fire mega-event
> 
>      Do similarly with the other controls that bother you.
> 
>      Also (and depending on the nature of your updates), you may
> gain by firing "specific" events instead of "catch-all" events.
> For example, a JTable might be more responsive if its model fired
> events reporting updates to three individual cells than if it
> fired "the whole table changed" events.  (This goes somewhat
> against the "fire mega-event" suggestion above, but that just
> means that engineering is the art of striking balances.)
> 

My JTable is working great.  I just ran a query and it took me about 10 seconds to return 59990 rows and put it all in the table.  That's 25 columns, individually doing a setValue for 1499750 cells.  This takes a lot longer if it's trying to repaint the table after every set.  If you're doing a full load you can just fireTableChanged one time at the end.  If you already have thousands of rows and you're updating a few dozen, a fireTableRowsUpdated may be more efficient, though there wasn't really a noticeable delay with my "fire mega event".

JTextArea is my next big control.  Normally we just do one insert, as we just use it to display about a dozen lines of text at a time.  Now I'm trying to make a file viewer.  I tried loading a text file into any number of text file editors but they just crash because it's too big (email dump).  I wanted to see if I can load the whole thing at once into a JTextArea.  If not I want to get as much as possible, then I can remove text if necessary to add more, with first/previous/next/last buttons to scroll through the file.  I have no problem reading multiple chunks from any point in the file, but I can't call the JTextArea insert multiple times in a row without locking up the EDT because it wants to repaint every time.

[toc] | [prev] | [next] | [standalone]

#38268

On 2018-05-22 22:20, Eric Douglas wrote:
> JTextArea is my next big control.  Normally we just do one insert, as we just use it to display about a dozen lines of text at a time.  Now I'm trying to make a file viewer.  I tried loading a text file into any number of text file editors but they just crash because it's too big (email dump).  I wanted to see if I can load the whole thing at once into a JTextArea.  If not I want to get as much as possible, then I can remove text if necessary to add more, with first/previous/next/last buttons to scroll through the file.  I have no problem reading multiple chunks from any point in the file, but I can't call the JTextArea insert multiple times in a row without locking up the EDT because it wants to repaint every time.
> 

You'll obviously need to page through the file. Check out
java.io.RandomAccessFile.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#38270

On Tuesday, May 22, 2018 at 4:48:33 PM UTC-4, Daniele Futtorovic wrote:
> On 2018-05-22 22:20, Eric Douglas wrote:
> > JTextArea is my next big control.  Normally we just do one insert, as we just use it to display about a dozen lines of text at a time.  Now I'm trying to make a file viewer.  I tried loading a text file into any number of text file editors but they just crash because it's too big (email dump).  I wanted to see if I can load the whole thing at once into a JTextArea.  If not I want to get as much as possible, then I can remove text if necessary to add more, with first/previous/next/last buttons to scroll through the file.  I have no problem reading multiple chunks from any point in the file, but I can't call the JTextArea insert multiple times in a row without locking up the EDT because it wants to repaint every time.
> > 
> 
> You'll obviously need to page through the file. Check out
> java.io.RandomAccessFile.
> 
> -- 
> DF.

I'm not specifically referencing RandomAccessFile, would that help anything?  I just read it like
File f = new File(inpFileName.getText());
FileInputStream fis = new FileInputStream(f);
FileChannel ch = fis.getChannel();
long fileSize = ch.size();
fis.close();
ByteBuffer buf = ByteBuffer.allocate((int)Math.min(64000,fileSize));
FileInputStream fisb = new FileInputStream(f);
FileChannel ch = fisb.getChannel();
int startPoint = 0;
ch.read(buf, startPoint);
fisb.close();
Then to see what's at the end of the file, just startPoint = fileSize - amountToRead.

[toc] | [prev] | [next] | [standalone]

#38274

On 2018-05-22 22:58, Eric Douglas wrote:
> On Tuesday, May 22, 2018 at 4:48:33 PM UTC-4, Daniele Futtorovic wrote:
>> On 2018-05-22 22:20, Eric Douglas wrote:
>>> JTextArea is my next big control.  Normally we just do one insert, as we just use it to display about a dozen lines of text at a time.  Now I'm trying to make a file viewer.  I tried loading a text file into any number of text file editors but they just crash because it's too big (email dump).  I wanted to see if I can load the whole thing at once into a JTextArea.  If not I want to get as much as possible, then I can remove text if necessary to add more, with first/previous/next/last buttons to scroll through the file.  I have no problem reading multiple chunks from any point in the file, but I can't call the JTextArea insert multiple times in a row without locking up the EDT because it wants to repaint every time.
>>>
>>
>> You'll obviously need to page through the file. Check out
>> java.io.RandomAccessFile.
> 
> I'm not specifically referencing RandomAccessFile, would that help anything?  I just read it like

Yes, seriously, it would. Have a look at the Javadoc
(<https://docs.oracle.com/javase/9/docs/api/java/io/RandomAccessFile.html>),
at the class definition, and search for usage examples if that's not enough.

Of course, that class will only come in handy if and when you give up on
the absurd notion of loading multi-gig files into RAM just in order to
show a couple lines of it. But then it most likely /will/ come in
handy... unless you have variable-length character encodings in it, in
which case you'd probably have to index the file before. But still.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#38275

On Tuesday, May 22, 2018 at 10:31:46 PM UTC-4, Daniele Futtorovic wrote:
> Yes, seriously, it would. Have a look at the Javadoc
> (<https://docs.oracle.com/javase/9/docs/api/java/io/RandomAccessFile.html>),
> at the class definition, and search for usage examples if that's not enough.
> 
> Of course, that class will only come in handy if and when you give up on
> the absurd notion of loading multi-gig files into RAM just in order to
> show a couple lines of it. But then it most likely /will/ come in
> handy... unless you have variable-length character encodings in it, in
> which case you'd probably have to index the file before. But still.
> 
> -- 
> DF.

That seems to work with the same code I mentioned, just putting this class in place of FileInputStream.  I'm not sure what you mean with the variable-length character encodings, but on a related note how do I display characters in JTextArea?  I tried reading a little PDF with this logic into a byte[] array, passing that into a String constructor, passing that into the insert method and I get a lot of squares.

[toc] | [prev] | [next] | [standalone]

#38277

On 2018-05-23 14:54, Eric Douglas wrote:
> On Tuesday, May 22, 2018 at 10:31:46 PM UTC-4, Daniele Futtorovic wrote:
>> Yes, seriously, it would. Have a look at the Javadoc
>> (<https://docs.oracle.com/javase/9/docs/api/java/io/RandomAccessFile.html>),
>> at the class definition, and search for usage examples if that's not enough.
>>
>> Of course, that class will only come in handy if and when you give up on
>> the absurd notion of loading multi-gig files into RAM just in order to
>> show a couple lines of it. But then it most likely /will/ come in
>> handy... unless you have variable-length character encodings in it, in
>> which case you'd probably have to index the file before. But still.
>>
> 
> That seems to work with the same code I mentioned, just putting this class in place of FileInputStream. 

Using the RandomAccessFile will allow you, for instance, to display just
the last page of the file without reading through all the previous data
(which would cause a delay).

> I'm not sure what you mean with the variable-length character encodings, 

I mean that if you have a fixed-length character encoding (say, ASCII or
UTF-16), you can compute the position of character N in the file (in
case of UTF-16, it would be at byte position N*2).

If you have variable-length encoding, you cannot do that. You would have
for instance to precompute the byte position of each line by doing a
pass on the whole file first; only after that could you page through it
(i.e., display line N to N+50).

> but on a related note how do I display characters in JTextArea?  I tried reading a little PDF with this logic into a byte[] array, passing that into a String constructor, passing that into the insert method and I get a lot of squares.

PDF is a binary file, not a text file. Everything I mentioned previously
was under the assumption that you were working with text files. If you
want to display a PDF, you'll likely be better off using a third-party
library (not sure those even exist for Java, but they may).

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#38278

On Wednesday, May 23, 2018 at 9:59:58 AM UTC-4, Daniele Futtorovic wrote:
> PDF is a binary file, not a text file. Everything I mentioned previously
> was under the assumption that you were working with text files. If you
> want to display a PDF, you'll likely be better off using a third-party
> library (not sure those even exist for Java, but they may).
> 
> -- 
> DF.

I am normally just looking at plain text files, but I did want to be able to view any file.  Other text editors handle binary.
If I view a binary file in Notepad++ it shows things like NUL STX SI EOT SUB DLE SO US SOH.  I don't know what these mean but it shows something, not squares.
PsPad has a special template now for PDF so it only shows the text content, not any of those unprintable characters.  If I view a true binary exe file with it, it shows columns, with unprintable characters on the right as dots and hex values of all characters on the left.

[toc] | [prev] | [next] | [standalone]

#38279

On 2018-05-23 16:26, Eric Douglas wrote:
> On Wednesday, May 23, 2018 at 9:59:58 AM UTC-4, Daniele Futtorovic wrote:
>> PDF is a binary file, not a text file. Everything I mentioned previously
>> was under the assumption that you were working with text files. If you
>> want to display a PDF, you'll likely be better off using a third-party
>> library (not sure those even exist for Java, but they may).
>>
>> -- 
>> DF.
> 
> I am normally just looking at plain text files, but I did want to be able to view any file.  Other text editors handle binary.
> If I view a binary file in Notepad++ it shows things like NUL STX SI EOT SUB DLE SO US SOH.  I don't know what these mean but it shows something, not squares.
> PsPad has a special template now for PDF so it only shows the text content, not any of those unprintable characters.  If I view a true binary exe file with it, it shows columns, with unprintable characters on the right as dots and hex values of all characters on the left.
> 

The "squares" appear because the font you're using does not have any
glyph for the codepoints that you're trying to show.

As for the rest... Good Luck!

-- 
DF.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web