This is a long-standing source of confusion with Shotwell. There are numerous issues involved.
First, Shotwell uses GDK Pixbuf to perform the rotate/flip operations in memory. Those operations are non-destructive and reversible.
Re-encoding a JPEG *is* destructive due to the lossy nature of JPEG compression. Older photo managers used generational editing, meaning they saved (re-encoded) the JPEG with each edit. This leads to loss of precision, detail, color, and more.
This is why Shotwell uses EXIF orientation whenever possible; by avoiding re-encoding the JPEG, we preserve the photo.
However, there is only one export case where Shotwell can use this technique: If the photo is being exported (a) at the same size (dimensions) as the original and (b) with no other transformations involved (cropping, red-eye, color adjustment, etc.) If either of these is not true, Shotwell must re-encode the JPEG, so it will go ahead and rotate the image along with the other transformations.
Note that there is a side-case as well: When metadata writing is turned on, Shotwell will write the Orientation out (along with keywords, titles, descriptions, etc.) This is a handy way to properly orient your master photos without re-encoding them (and losing the detail in the originals).
For most photo sharing services, the photo must be uploaded at a smaller size than the original, so the orientation issue is moot. For situations where the original is being uploaded (again, with no other transformations), then yes, only the EXIF Orientation is modified.
The problem with re-encoding every time is that we don't know the purpose of the export. If it's to share baby photos on Facebook or Instagram, then yeah, re-encoding is probably not a big deal. But if it's being exported for archival purposes (which some people use Flickr for), then we're needlessly removing detail from their photos. For some people, it's no big deal. For others, it's like we're repartitioning their hard drive.
This is a long-standing source of confusion with Shotwell. There are numerous issues involved.
First, Shotwell uses GDK Pixbuf to perform the rotate/flip operations in memory. Those operations are non-destructive and reversible.
Re-encoding a JPEG *is* destructive due to the lossy nature of JPEG compression. Older photo managers used generational editing, meaning they saved (re-encoded) the JPEG with each edit. This leads to loss of precision, detail, color, and more.
This is why Shotwell uses EXIF orientation whenever possible; by avoiding re-encoding the JPEG, we preserve the photo.
However, there is only one export case where Shotwell can use this technique: If the photo is being exported (a) at the same size (dimensions) as the original and (b) with no other transformations involved (cropping, red-eye, color adjustment, etc.) If either of these is not true, Shotwell must re-encode the JPEG, so it will go ahead and rotate the image along with the other transformations.
Note that there is a side-case as well: When metadata writing is turned on, Shotwell will write the Orientation out (along with keywords, titles, descriptions, etc.) This is a handy way to properly orient your master photos without re-encoding them (and losing the detail in the originals).
For most photo sharing services, the photo must be uploaded at a smaller size than the original, so the orientation issue is moot. For situations where the original is being uploaded (again, with no other transformations), then yes, only the EXIF Orientation is modified.
The problem with re-encoding every time is that we don't know the purpose of the export. If it's to share baby photos on Facebook or Instagram, then yeah, re-encoding is probably not a big deal. But if it's being exported for archival purposes (which some people use Flickr for), then we're needlessly removing detail from their photos. For some people, it's no big deal. For others, it's like we're repartitioning their hard drive.